We now know that the next version of Chrome/Edge breaks editing in current versions of TiddlyWiki:
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.
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.
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.
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.
â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.
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:
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.
The Chromium commit that introduced the problem was reverted in this commit:
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.
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.
