2ch.hk is displaying incorrectly

[Kinpouge]

With Palemoon 28.14.0, a site 2ch.hk is displaying incorrectly.

How it is now (screenshot of 2ch.hk/bo)

Clipboard-2-fs8.png

How it should be:

Clipboard-1-fs8.png

Browser is running in "Safe mode".

[Moonchild]

According to the CSS this is exactly the way it should be displayed.

flexbox container,
header: flex 1 100% <-- this is a mistake, I'm sure they meant 1 0 100% if they wanted the header to fill the top space -- Since this doesn't parse it will default to auto
aside: flex 0 0 250px (fixed size 250 px)
main: flex 1 1 (= 1 1 auto, meaning fill the remaining space)

Result, 3 columns evenly spaced left/right with 250 px middle column.

If they'd fix their css mistake in the header, it will display as-expected. (which is not what you think "how it should be" because it's missing the "aside" column entirely)

[JustOff]

Sorry, but I still have some doubts about this issue because all other browsers render this page the same way as Pale Moon 28.13.0 and the layout became broken only after Issue #1647 (UXP) was landed. Isn't this a regression?

[Moonchild]

We didn't change the parsing of flex, at all. Not even touched anything near it.

[JustOff]

I don't have an explanation of how exactly this affected, but sequential test builds clearly point to commits from Issue #1647 (UXP).

[Moonchild]

It -is- quite possible that the error was interpreted differently before the update. Being interpreted as flex 1 0 (=grow, don't shrink) before (because the percentage didn't serialize) and being interpreted as flex 1 1 (=grow or shrink) now (because it serialized to 100%=1)
@athenian200, layout/inspector/inDOMUtils.cpp Line 845, was that correct? or should that have been with fill/stroke above it? there's no opacity on grid keywords font weight or initial_letter, afaik, but there would be on fill/stroke, and that might influence flex?

[athenian200]

I don't have an explanation of how exactly this affected, but sequential test builds clearly point to commits from Issue #1647 (UXP).

Thank you for helping me find the issue with my code! Really wish I had noticed that before release, but better late than never.

It -is- quite possible that the error was interpreted differently before the update. Being interpreted as flex 1 0 before (because the percentage didn't serialize) and being interpreted as flex 1 1 now (because it serialized to 100%=1)
@athenian200, layout/inspector/inDOMUtils.cpp Line 845, was that correct? or should that have been with fill/stroke above it? there's no opacity on grid keywords font weight or initial_letter, afaik, but there would be on fill/stroke, and that might influence flex?

Actually, that line shouldn't have been there at all. I was going out of my way to make sure VARIANT_OPACITY was parsed in all/most of the same cases VARIANT_NUMBER is because I didn't want my implementation to break unexpectedly by failing to allow percentages to serialize as numbers. However, it worked a little too well... I added it to so many places that it serialized a percentage as a number in a situation where it shouldn't, which kind of defeats the main point of having VARIANT_OPACITY rather than just adding a new case for VARIANT_NUMBER that accepts percentage tokens and converts them to numbers if serializing as a percentage isn't allowed (what you saw just now is precisely why I couldn't simply do it that way).

It's actually kind of weird that this issue came up, though. You would think if a field didn't allow percentages, people wouldn't use percentages there, much less depend on the behavior that results from what they entered not being allowed. But the spec is the spec, and website authors apparently rely on it being EXACTLY what it is in all sorts of subtle/weird ways you wouldn't expect.

[Moonchild]

I don't think they relied on it here, per se, but rather that they didn't notice their mistake because it happened to work in the way they intended

[New Tobin Paradigm]

Which is the entire prpblem with coding for only one browser and the quirks of one engine being the so called reference implementation.

The spec is not the spec but Google's implementation, as always.

[badnick]

Such like issue I reported here
viewtopic.php?f=29&t=25236&p=200514#p200514

[Tharthan]

Off-topic:

The spec is not the spec but Google's implementation, as always.

This ought to be raised in the antitrust probe (as a "and not to mention!" type comment), because on a practical level it means that anyone who actually tries to use a different browser from Chrome/Chromium [read: us. Pretty much just us nowadays] is made to leap through hoops to get many websites to work.

[Moonchild]

Off-topic:

This ought to be raised in the antitrust probe (as a "and not to mention!" type comment), because on a practical level it means that anyone who actually tries to use a different browser from Chrome/Chromium [read: us. Pretty much just us nowadays] is made to leap through hoops to get many websites to work.

Trust me I've already raised this point in my communication with the DoJ.

[Moonchild]

This issue is resolved, will be in the next update. Still doesn't take away that 2ch.hk needs to fix their mistake

[JustOff]

Thank you for helping me find the issue with my code! Really wish I had noticed that before release, but better late than never.

I'm glad it was helpful. It's impressive how quickly you sorted things out after that.