xkcd.com - Page not rendered correctly

[webcompat-bot]

URL: https://xkcd.com/2347/

Browser / Version: Firefox Mobile 126.0
Operating System: Android 14
Tested Another Browser: Yes Chrome

Problem type: Design is broken
Description: Items are misaligned
Steps to Reproduce:
On various sites the table, frame and image design and placed is broken. This one shows the most damage

View the screenshot

Browser Configuration

• gfx.webrender.software: false
• blockList: basic
• defaultUserAgent: Mozilla/5.0 (Linux; Android 14; Mobile; rv:126.0) Gecko/126.0 Firefox/126.0
• hasTouchScreen: false
• frameworks: {'fastclick': False, 'mobify': False, 'marfeel': False}
• mixed active content blocked: false
• mixed passive content blocked: false
• tracking content blocked: false

View console log messages

From webcompat.com with ❤️

[sv-calin]

Thank you for reporting this issue, I was able to reproduce it.

Firefox Nightly

Firefox Release/Beta

Tested on:
• Browser / Version: Firefox Nightly 126.0a1-20240404213056 / Firefox Release 124.0.2-20240401114208 / Firefox Beta 125.0-20240405130120 / Chrome 123.0.6312.40
• Operating System: OnePlus 6 A6000 (Android 11) - 1080 x 2280 pixels, 19:9 ratio (~402 ppi pixel density)

Notes:

1. Reproducible on Firefox Nightly
2. Not reproducible on Chrome, Firefox Release and Beta

Moving to Needsdiagnosis.

[qa_15/2024]

[dholbert]

@sv-calin Is this still reproducible?

It looks like we're entirely failing to render certain parts of the page (in particular the gray bold link text at the top-right next to "is on YouTube" and at the bottom under "Comics I Enjoy"). I'm suspicious this was a graphics/driver bug, which has perhaps/hopefully been resolved? (I can't currently reproduce on my Pixel 8 Android phone at least, with Nightly 127 / Beta 126.)

[dholbert]

Given the issues with painting certain text on specific Android hardware, this seems possibly-similar to bug 1884791, but it's not quite the same, based on the timeline/versions-affected. (This WebCompat bug-report here seems to have been reproducible on v126, as of a few weeks ago, whereas bug 1884791 appeared in the 125 Nightly cycle and was fixed in that cycle.)

CC @jamienicol in case he's got any ideas about what might be going on, though (pending confirmation of whether this is still reproducible).

[dholbert]

(I'm also not clear on what the issue that the original reporter was seeing here, and whether it's the same as what @sv-calin saw.

The original reporter's screenshot seems to show the top-left portion of a XKCD page, as if they were simply zoomed in to that portion of the page. I'm guessing that this bug report is an indication that this is just how XKCD rendered for them, but it's hard to know for sure since there's no browser/phone UI shown in their screenshot. In any case: unlike @sv-calin's screenshot, the original screenshot's layout/rendering seems to be correct, aside from the fact that it's zoomed in and cropped (which is indeed annoying, if that's how the site loads).

Anyway: given that this came in via the webcompat-bot, we have no way of clarifying that or following up with the reporter, so it probably makes sense to just focus on @sv-calin's screenshotted rendering issues here (until/unless we discover more about what's going on in the original reporter's screenshot).

[jamienicol]

Yeah it's not bug 1884791, as you say the timeline doesn't match up and the symptoms are slightly different, and it's different hardware than @sv-calin.

I agree it's not clear what the original screenshot was showing. I wonder if perhaps when submitting a report we programmatically take a screenshot within firefox? If so, that would exercise a different rendering path which may not show the issue that the reporter saw with their eyes. It's unfortunate that the report does not contain the phone model or GPU...

I think I have the OnePlus 6 that sv-calin has, so I can try to reproduce on that. However, I think we had some temporary breakage on nightly around the time of sv-calin's comment that affected all platforms - so perhaps this is now fixed. @sv-calin can you still reproduce?

[dholbert]

I agree it's not clear what the original screenshot was showing. I wonder if perhaps when submitting a report we programmatically take a screenshot within firefox? If so, that would exercise a different rendering path which may not show the issue that the reporter saw with their eyes. It's unfortunate that the report does not contain the phone model or GPU...

We do indeed programmatically take a screenshot within Firefox, yeah. I reported a test issue #136522 earlier today to see what that flow is like; it seems to just capture the entire viewport (as if the dynamic toolbar were scrolled out of view, even if it's not), and then present that to you as part of the issue-submission process (with an opt-out if you decide not to include it).

I'm betting the user tried to zoom in on some of the breakage before filing their issue, and that's why the screenshot in comment 0 is zoomed in (though perhaps our screenshotting codepath didn't exercise the broken rendering path as jnicol noted, which is why nothing looks amiss, even though it probably did for the user when they went to file the issue).

So: it does seem quite possible that the original user was seeing the same thing that @sv-calin screenshotted after all, and our automatic in-browser screenshot just didn't pick it up.

So we can consider that thread closed :) And now the only open question is just whether @sv-calin (or jnicol-on-his-OnePlus6) can repro at this point; hopefully not?

[sv-calin]

I'm no longer reproducing the issue.

Tested on:
• Browser / Version: Firefox Nightly 128.0a1-20240525201917 (Build #2016022983) / Firefox Release 126.0-20240509170740
• Operating System: OnePlus 6 A6000 (Android 11) - 1080 x 2280 pixels, 19:9 ratio (~402 ppi pixel density)

[inv_22/2024]