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.
@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?
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.
Ciao @jeremyruston. I am looking at this as a technically naïve user & getting a bit lost.
What I am unclear about is actually whether it is wrong to start with??
Just a side comment
TT
“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.
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.
As I wrote in the other thread, there is a general problem with the event delegation in Edge 100.
So that 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
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
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:
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.
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
The Chromium commit that introduced the problem was reverted in this commit:
https://chromium.googlesource.com/chromium/src/+/abadd1181ca70cf3d1ac7e7878d46b1d3173a2e0
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.
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.
I think we’re going to need a chart somewhere telling us what versions of TW work with what versions of chromium derivatives.
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.
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.
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.
It appears that Blink and Chrome use the same versioning scheme based on the underlying Chromium milestone versioning system. If that’s true then it should just be v100 and v101 across the board that cause problems.
I usually run Edge Dev and noticed it, but I didn’t realize it was a general problem. I thought it was just due to my particular wiki. There is an internal site at my work that seems to have the same problem so Tiddlywiki isn’t the only site affected.
Is that a TW thing or something else? If not TW, was it written in-house or is it a solution provided by someone else?
No, it was a completely different site. That’s why I’m going to try and report this at least to the Edge team since I can contact them more easily than the Chromium team. I think Tiddlywiki should try and fix this issue itself since it may be impossible to fix this issue within the browsers for the scheduled release since I assume there are security updates/bug fixes that can’t be delayed.
