Tiddler buttons not working with v100 of Microsoft Edge

#1

Here’s a heads-up for anyone that might attempt to provide support for users.

I primarily use Microsoft Edge (Version 100.0.1185.12 (Official build) beta (64-bit)).

As of today, which brought me a new beta update to Edge, I can’t use the save, discard, delete buttons on my tiddlers. The “save site” button still works, but leaves in-edit tiddlers as drafts. The buttons are completely ignoring my mouse (not even making the mouse pointer change to a “you can click here” pointer).

I’ve tested this on a freshly-downloaded empty.html from the TW site and also my own TWs and even some others.

Chrome is working fine. However, Chrome is on the latest version, 99, which is not beta.

For both browsers, I’m using Timimi.

Here’s hoping Chrome v100 doesn’t mess stuff up, too, or that it’s fixed upstream before Chrome launches 100.

image

1 Like
Imminent release of TiddlyWiki v5.2.2 to address new Chrome/Edge bug
#2

As a follow-up, I installed v99 (current stable, non-beta) of MS Edge. The v99 kept all my extensions and settings from v100 without problems.

…and the buttons work again.

Bother! I’m afraid of v100 of both Chrome and Edge when they get here.

#3

Is this the same behaviour if you use tiddlywiki.com? That would be interesting. …

I do know a similar problem, that can happen if someone changes the Theme tweaks in the wrong way.

#4

Unfortunately, yes.

In my wild frenzy of testing how wide-ranging the problem was, I even checked on @arunnbabu81’s test site at Test — 1.0 (tiddlyhost.com) and it behaved fine. It was the only one I tested that worked without issue.

#5

I had a quick look and could reproduce the problem, seems to be a CSS issue. A symptomatic fix is easy but the real issue is figuring out what has changed with the browser rendering/CSS support.

#6

They don’t write something here: Microsoft Edge release notes for Beta Channel | Microsoft Docs

What’s the fix? May be we get some clues from the fix?

#7

Edge uses Chrome’s engine. I haven’t tried Chrome v100 yet. Maybe the issue is upstream in the engine itself and that’s why it’s not listed in Edge’s update notes.

#8

So in the edit template, clicks on the tiddler toolbar are actually received by the outermost span.tc-keyboard in the edit template.

image
image679×537 26.7 KB

Since the events are never triggered on the buttons, they don’t work.

Adding this CSS resolves the issue in some extremely limited testing:

.tc-tiddler-frame .tc-tiddler-controls {
    position: relative;
}

However, for a reliable fix we need to understand the underlying issue.

#9

How did you manage to test Edge v100? I don’t want to switch my system from “stable” to “insider”, to get early updates.

#10

You could setup a few VMs and not touch your personal environment. That way, you can use all kinds of setups and have no impact on anything else.

I have 6 x Win10 setups purely for testing all running unActivated copies of Win10.

Or something like browserstack perhaps?

#11

I used a VM but the Edge beta installer installs alongside the stable I believe: Microsoft Edge Insider

1 Like
#12

I only have Edge Beta on my home computer and I’m at the office right now. If I remember to, I will look to see how it’s installed.

But I do know that I have them installed in parallel. I can run v99 and v100 simultaneously. I believe (but have not verified) that the profiles are separate, too.

Mind you, if you use the MS synching feature as I do, it still feels like the same profile. But I’m fairly certain it’s a separate profile because I had to tell v100 to no longer run my PWA apps on startup and set them up in v99.

However, if you truly want to isolate things, by all means use a VM. That makes the most sense.

#13

This works, too (without tinkering with positioning).

span.tc-keyboard {
    display: block;
}
#14

I’m already using a VM to create my videos. I did make a copy and installed the beta version. It’s 100 already. So I can confirm the problem. … We will have a closer look, if we can replicate it in a generic way. Maybe somewhere at MDN which would make an error report much easier.

#15

Chrome 100.x has the same issue - blink problem, it seems. .tc-keyboard { display:block; } works there too, as you’d expect.

#16

It’s definitely a browser problem. … If I do a right-click : Inspect … It also selects the wrong element in the DOM-inspector. … So we need to try to create a simple HTML file, that causes the same problem. …

I’m not sure if they will have a look, if we present them our complex app as a test-case

#17

Totally agree. That’s a problem I’ve hit before with TW - how to create a minimal TC. I spent a few minutes doing as you suggested, trying to find a similar failure on MDN but failed to find anything.

I’m only 90% in favour of a bug diagnosis. But to explain the issue and possible cause might prove difficult. But here goes…

The keyboard widget is creating a SPAN. Without styling, as you know, a SPAN is an inline “flow content” element. However, it seems the buttons’ parent .tc-tiddler-controls with styling float:right introduces a new “Block formatting context” where “inline” is implicitly changed to “block” (ref).

It seems most likely Blink is getting that wrong, where the parent inline SPAN is not honouring the possibility that a child may have switched to “block”. Either that, or Blink is correct and we should make sure the “inline” elements don’t contain “block” elements.

So, semantically, I think Blink is correct. But, in terms of “don’t break the web”, I do wonder if it’s undesirable for Blink to disallow the possibility that there’s code out there that uses, in effect…

<inline-element>
  <block-element/>
</inline-element>

Lastly, what compounds it for me, is trying to get a single source of knowledge that spans both the HTML spec and the CSS spec.

Finally lastly ( :wink: ) having forced myself to write this out, now I’m 99% sure it’s not a bug in Blink. We should not be introducing blocks inside inline flow content.

Maybe.

:confused: :sweat_smile:

#18

The DIV inside SPAN thing due to how we use $reveal widgets (no tag attribute) has always annoyed me a fair bit. I am not sure if it was done this way as an oversight or because we felt it would make it easier for end users to style the elements children to their liking with less need for custom CSS.

For this particular issue it would be good to know if this is indeed the cause and that the browser handling in this respect has changed and in precisely what way. Otherwise any fix we attempt may only be kicking the problem down the road or it may surface in other places.

Also note: If you give the outermost span.tc-keyboard the display property block, the buttons work again even though at this point there is still another span inside which contains a div which contains the buttons…

#19

Yep, as I posted above. That’s the “best” fix, for me.

And, FWIW, I’m not longer 99% sure of anything. The more I think about the possible root cause, the more confused I get. :confused:

#20

FWIW, in Firefox devtools, I watched the display property in the computed style pane for the .tc-tiddler-controls as I enabled/disabled the float:right setting. Sure-nuff, it toggled from inline to block to inline.

I might spin the VM up again to try Blink later. Or someone else can… might lead to a cause?