Imminent release of TiddlyWiki v5.2.2 to address new Chrome/Edge bug

[jeremyruston]

We now know that the next version of Chrome/Edge breaks editing in current versions of TiddlyWiki:

Tiddler buttons not working with v100 of Microsoft Edge

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 thi…

Chrome 100 is due to be released on March 29th, and Edge 100 in the week of March 31st.

It looks like this will have a very significant impact for us. It means that at a stroke users who upgrade to the new version will not be able to make edits to tiddlers.

So, not only do we need to make a new release of TiddlyWiki to address the problem, but all existing TiddlyWiki installations will have to be upgraded.

I’m hopeful that we’ll be able to mitigate the problem in some cases. For example, it may be possible to make a bookmarklet that could be used to “fix” older wikis to allow editing in Chrome 100.

There’s a lot to do over the next few days to address this: we have to come up with a fix, test it, and make the new release.

[abesamma]

It’s pretty irritating to see how many things will break because of browser vendors’ upgrades to v100. I hope we can still maintain backward compatibility despite all this.

[abesamma]

The alternative is to use Firefox. Which brings me to my question: any Firefox nightly users seeing something similar?

[linonetwo]

I’m in Firefox 99.0b7 beta channel and it works without bugs.

[jeremyruston]

One slightly disappointing thing about this episode is that we only discovered the problem a few days before the final release of these browsers.

Ideally, many more of us would be running beta versions of the major browsers so that we get earlier warnings of problems. As far as I can tell, the bug would have been present in Google’s Chrome Canary release at some point in January/February, which would have given us a much more comfortable response time.

[TW_Tones]

@jeremy what do you make of my test with Google Chrome Chrome Version 102.0.4956.0 (Official Build) canary (64-bit)in Windows 11

The problem is not occuring with it?

[jeremyruston]

@TW_Tones

@jeremy what do you make of my test with Google Chrome Chrome Version 102.0.4956.0 (Official Build) canary (64-bit)in Windows 11

I get the same results: the bug occurs with v100 and v101 but not with v102. I guess it means that this bug might end up going away by itself, so to speak, but it doesn’t help much with the weeks during which almost all Chrome users will be on v100 or v101.

[TiddlyTweeter]

@jeremyruston

I guess it means that this bug might end up going away by itself, so to speak, but it doesn’t help much with the weeks during which almost all Chrome users will be on v100 or v101.

Ciao @jeremyruston. I am looking at this as a technically naïve user & getting a bit lost.

• If the issue is “block inside span” is technically illegal should it not be changed anyway?

What I am unclear about is actually whether it is wrong to start with??

Just a side comment
TT

[CodaCoder]

@TiddlyTweeter

What I am unclear about is actually whether it is wrong to start with??

“Wrong” and “illegal” are relative terms here. Browsers are, correctly, forgiving – they typically allow semantically and structurally incorrect composition for reasons of both backward compatibility and “don’t break the web”. The latter is the affordance that a web page written in 1995 still works today.

For us, the extraordinary problem is that a million (pulled that number out of thin air) TW-based sites will, over night, stop working in the most popular rendering engine on (and off!) the planet.

Further, we don’t know that my suspicion (because that’s all it is) about “block in span” is correct [EDIT: except now we DO] – what’s clear is, at that specific point in the document hierarchy, event delegation appears interrupted (if not entirely broken).

By “rights”, the browsers should be fixed such that they don’t break the web. Problem: there’s no time. Little old us cannot stop the release cadence or even pause it.

[jeremyruston]

@TiddlyTweeter

If the issue is “block inside span” is technically illegal should it not be changed anyway?

We do not know whether that is the problem, at this point we only know that changing the spans to divs is one way to fix the problem. The trouble is that we have discovered several different ways of fixing the bug, and the way that they work is not related (for example, removing the edit template segment containing the title field editor fixes the problem without changing any other HTML or CSS).

So, we will probably fix the span issue anyway because it makes sense to do things the ‘right’ way. But we are continuing to investigate the bug to find out the actual root cause.

[pmario]

@jeremyruston

So, we will probably fix the span issue anyway because it makes sense to do things the ‘right’ way. But we are continuing to investigate the bug to find out the actual root cause.

As I wrote in the other thread, there is a general problem with the event delegation in Edge 100.

• If you open a tiddler in edit mode with eg: Edge 100
• If you right-click the “Cancel button”
• Select the “Inspect” function
• It “inspects” the wrong element. …

So that seems to be a general problem with the browser.

[TiddlyTweeter]

@pmario

… seems to be a general problem with the browser.

Right. The issue for an idiot user like me is simple. Too much hassle.

TBH, I think the issue illustrates the issue of “who controls what?” (Paranoia off)

TT

[TiddlyTweeter]

@jeremyruston

We do not know whether that is the problem, at this point we only know that changing the spans to divs is one way to fix the problem. The trouble is that we have discovered several different ways of fixing the bug, and the way that they work is not related

I think you guys brilliant.

TBH, I was very surprised the issue ever arrived.
To me, naively, it looks like super-dad quashing his progeny.
It is a horrible thing.

Just moaning, TT

[jeremyruston]

This is somewhat technical, but I’ve been using a special tool from Google that allows one to test bugs against arbitrary versions of Chrome, using a bisect algorithm to efficiently isolate the problem:

https://www.chromium.org/developers/bisect-builds-py/

I’ve tracked down the introduction of this issue to this change:

https://chromium.googlesource.com/chromium/src/+/4a76c96d2a4021257e691058c1fe1fb60d9d8327

It is the implementation of this proposal to change the way that block elements are handled inside inline elements:

Blocks in Inline (no-split-inline)

Stunningly, the document makes it clear that they knew that it was a breaking change, but that they went ahead with it.

I will shortly run the bisect process again to find where the problem was fixed in v102.

[EricShulman]

@jeremyruston

…at this point we only know that changing the spans to divs is one way to fix the problem…

Will changing from SPAN to DIV affect the layout (i.e., force things to start on a new line instead of “in the flow”)?

Perhaps using CSS “display:inline-block” could be a better option, i.e.,
.tc-keyboard { display:inline-block; }
as that might technically make the keyboard elements block-level, while still rendering them “in the flow” as they are now.

Note: a quick test on https://TiddlyWiki.com shows that using either display:block or display:inline-block causes layout changes: display:block adds a line break within the top bar menu, while display:inline-block makes the tiddler editor layout no longer the full width of the tiddler frame.

To address this, I found that using
.tc-keyboard { display:inline-block;width:100%; }
seems to prevent both unwanted side effects.

The only question is, does this actually avoid the original problem?

I’m not set up to try v100 browsers, so I will leave that test for others to persue.

-e

[CodaCoder]

@EricShulman

.tc-keyboard { display:inline-block; }

As we suspected, it works…

[jeremyruston]

The Chromium commit that introduced the problem was reverted in this commit:

https://chromium.googlesource.com/chromium/src/+/abadd1181ca70cf3d1ac7e7878d46b1d3173a2e0

@EricShulman

Will changing from SPAN to DIV affect the layout (i.e., force things to start on a new line instead of “in the flow”)?

No, there should not be any visible change. It may affect some CSS selectors that reference the span elements directly, but that does not happen in the core. I’ll merge the PR shortly so that we can verify things.

[TW_Tones]

Is there any practical possibility or reason to try and thwart this change, through the upgrade dev process for chromium, especially if it is observed fixed in a later version?

We could say that our fix is for the future, and not for the past and tiddlywikis will get damaged all over the world and need a patch? At least we need to find all public versions out there. Private versions, fine, on first use apply the bookmarklet, but published versions may need download/ediot/upload etc…

I have not yet found an easy way to distribute bookmarklet’s but publishing it on tiddlywiki.com will help, + a json or even a plugin in the core plugins (on back versions?).

Perhaps, any neglected ones will be fixed with the passing of time, as the browser is updated. But perhaps we need this officially recognised, or perhaps there is technically a tiddlywiki design error?

You don’t need to answer me, only consider what I say, as I defer it to others who know.

[Mark_S]

I think we’re going to need a chart somewhere telling us what versions of TW work with what versions of chromium derivatives.

[jeremyruston]

@TW_Tones

Is there any practical possibility or reason to try and thwart this change, through the upgrade dev process for chromium, especially if it is observed fixed in a later version?

Not at this point in their development cycle. There’s zero chance that Chromium developers would have considered TiddlyWiki to be important enough to warrant a change, but there’s a small chance that we could have got together with other affected groups, and perhaps influenced things quicker. It’s clear that Google did respond to pressure to revert the change, but sadly the bug report they reference is private to Google.

@TW_Tones

I have not yet found an easy way to distribute bookmarklet’s but publishing it on tiddlywiki.com will help, + a json or even a plugin in the core plugins (on back versions?).

The usual way is to publish them as links within HTML pages (or TiddlyWiki), and instruct users to drag the link to their bookmarks bar.

@TW_Tones

At least we need to find all public versions out there. Private versions, fine, on first use apply the bookmarklet, but published versions may need download/ediot/upload etc…

As far as we know, the bug only affects the ability to edit tiddlers, so it isn’t necessary to update public TiddlyWiki’s that are not being updated.