New Tab placeholder tiles are skinny "matchsticks" until their content renders
Categories
(Firefox :: New Tab Page, defect)
Tracking
()
People
(Reporter: dholbert, Unassigned)
References
(Regression)
Details
(Keywords: regression)
Attachments
(5 files)
[Tracking Requested - why for this release]: late breaking regression, recently uplifted to beta135
STR:
- Start Firefox with a fresh profile, viewing
about:home
, like this on Linux:
mkdir /tmp/temp-profile; firefox -profile /tmp/temp-profile "about:home"
- Watch the new-tab page very carefully as it loads.
ACTUAL RESULTS:
The new-tab suggested-stories tiles are very skinny while they're waiting for their content (and while they're playing their "throbber" loading animation)
EXPECTED RESULTS:
No such skinny rendering.
This is a recent regression, regression range:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=87dd25bcdd3ba49dfdda30cc90af054aaa07c99e&tochange=c59212ed5dcd997a87cabbe46fa2946c246d792a
--> regression from bug 1939415. We've got limited time to investigate/fix because it looks like bug 1939415 was uplifted to beta135 which goes to release-candidate next week, I think.
Reem, could you take a look at this?
Reporter | ||
Comment 1•22 days ago
|
||
Reporter | ||
Comment 2•22 days ago
|
||
Reporter | ||
Comment 3•22 days ago
•
|
||
The broken rendering goes away pretty quickly for me in official builds (e.g. the Nightly screencast in comment 1), but it's still noticeable.
But it lasts many seconds in a local enable-debug/disable-optimize build -- here's a screencast showing that, where we've got the broken rendering from t=0:27 to t=0:37 (ten full seconds).
I'm guessing (but haven't yet confirmed) that the limiting factor here (on when we switch from bad to good rendering) is whether we've gotten the new-tab-tile data back from Firefox's server that provides that. If that is indeed true, then I would imagine that folks on slow connections might see this broken rendering for many seconds even in optimized official builds (looking something like this screencast).
Reporter | ||
Comment 4•22 days ago
•
|
||
(In reply to Daniel Holbert [:dholbert] from comment #3)
I'm guessing (but haven't yet confirmed) that the limiting factor here (on when we switch from bad to good rendering) is whether we've gotten the new-tab-tile data back from Firefox's server that provides that.
Update: it looks like these tiles reach their ~correct width when either...
(a) their content arrives (that's what makes them wide at t=37s in the debug screencast in comment 3)
...OR:
(b) the square "shortcuts" row renders (that's the instigating factor just before things become fixed at t=3s in the Nightly screencast in comment 1) -- presumably this "shortcuts" row provides a wider content-width for some wrapper-element, which then gets these otherwise-squished tiles to stretch to fill that wrapper-element.
I think both of those are conditional (at least in part) on getting a response from the server, the first time at least -- so we probably don't want to be at the mercy of these two factors in order to render proper-looking new-tab suggested-story tiles.
Comment 5•22 days ago
|
||
Set release status flags based on info from the regressing bug 1939415
Updated•22 days ago
|
Comment 6•22 days ago
|
||
The bug is marked as tracked for firefox135 (beta). We have limited time to fix this, the soft freeze is in 8 days. However, the bug still isn't assigned.
:thecount, could you please find an assignee for this tracked bug? Given that it is a regression and we know the cause, we could also simply backout the regressor. If you disagree with the tracking decision, please talk with the release managers.
For more information, please visit BugBot documentation.
Comment 7•21 days ago
|
||
Seems this is a similar issue to this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1942539
Reporter | ||
Comment 8•21 days ago
|
||
Yup, same issue I think.
Reporter | ||
Comment 9•20 days ago
•
|
||
I confirmed bug 1942539 has the same regressor. That one is probably easier to diagnose/investigate (and more severe/noticeable) because the rendering is persistently-broken -- it's not just a temporary misrendering like in this bug here.
In any case, though, we've got extremely limited time to address these, since this affects 135 (current beta) which goes to release-candidate next week and becomes the official release in 12 days based on https://whattrainisitnow.com/ .
Reporter | ||
Comment 10•20 days ago
|
||
(See https://bugzilla.mozilla.org/show_bug.cgi?id=1942539#c5 for some analysis of the specific css rule and specific element that's involved here)
Comment 11•20 days ago
|
||
This bug reads as a duplicate of bug 1942539 to me, so closing this one to consolidate discussion. :-)
Reporter | ||
Comment 12•20 days ago
|
||
FWIW another way to trigger this version of the bug (that doesn't require starting with a fresh profile as in comment 0) is just to disable all new-tab sections in the cog menu, and then selectively toggle "Recommended Stories" to be enabled/disabled. There's a flash of very-skinny tile UI as the tiles come back each time.
Here's a screencast demonstrating that. As in comment 1, the misrendering is very brief, but it's noticeable. (It sorta looks like the tiles are "accordion"-uncollapsing outwards.)
Reporter | ||
Comment 13•20 days ago
•
|
||
In case it's hard to see in the actual screencast (since the misrenderings are so brief): here's a screenshot from t=7s in the screencast that I just attached, demonstrating the broken rendering briefly showing when the suggested-stories tiles reappear.
Updated•20 days ago
|
Reporter | ||
Comment 14•19 days ago
•
|
||
Verified fixed by the patch that landed on the dupe target, as noted in bug 1942539 comment 22. --> Verified dupe.
Description
•