1935927 - Tables not rendering in adminconsole.adobe.com (render on 133-release)

Status: RESOLVED FIXED

(Core :: Layout: Tables, defect)

Description

[oneofthedamons]

Attachment: 134-beta Overview Admin Console.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:134.0) Gecko/20100101 Firefox/134.0

Steps to reproduce:

I'm moving https://github.com/webcompat/web-bugs/issues/144754 to here because I can replicate this reliably on 134-beta but cannot replicate on 133-release.

Some tables in adobeconsole.adobe.com are not being rendered properly in 134-beta. This seems to be a bug introduced in 134 as I cannot replicate it in 133-release, even in a new profile on a newly imaged Windows 10 machine.

Actual results:

The table of Products in https://adminconsole.adobe.com/<our_org_ID>@AdobeOrg/overview is not rendered.
The table of Products in https://adminconsole.adobe.com/<our_org_id>@AdobeOrg/products is not rendered.
The table of Users in https://adminconsole.adobe.com/<our_org_ID@AdobeOrg/users is not rendered.
The table of Packages in https://adminconsole.adobe.com/<our_org_id>@AdobeOrg/packages/all-packages is not rendered.

Expected results:

The above tables should be rendered properly as they are in 133-release.

Comment 1

[oneofthedamons]

Attachment: 133-release Overview Admin Console.png

Compare with 133-beta Overview Admin Console

Comment 2

[oneofthedamons]

(In reply to oneofthedamons from comment #1)

Created attachment 9442353 [details]
133-release Overview Admin Console.png

Compare with 133-beta Overview Admin Console

sorry I meant 134-beta Overview Admin Console

Comment 3

[oneofthedamons]

Attachment: 134-beta All products and services Admin Console.png

Comment 4

[oneofthedamons]

Attachment: 133-release All products and services Admin Console.png

Compare with 134-beta All products and services Admin Console

Comment 5

[oneofthedamons]

Attachment: 134-beta packages Admin Console.png

Comment 6

[oneofthedamons]

Attachment: 133-release packages Admin Console.png

Compare with 134-beta packages Admin Console

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Layout: Tables' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 8

[oneofthedamons]

If it helps I can post the markup of these as it will require an account to view, just let me know.

Comment 9

[Mayank Bansal]

1.Please share a testcase. Without a reproducible testcase, this bug will be infeasible to diagnose and fix.
2. Given that you know it works well in Firefox 133 release, can you do a bisection to find the exact change that caused this (https://mozilla.github.io/mozregression/). The Windows GUI version of mozregression is particularly easy to use and needs no installation.

Comment 10

[oneofthedamons]

Thanks, Mayank — mozregression is cool! It revealed the change associated with the issue is Bug 1768921. Here is the pushlog URL: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=784d36031f308d8aff8b563ed92e5e68f5943094&tochange=9e5a9d145ebeeb3a0b8814c0471de838a6aaf2e2

In terms of a testcase, I will look into if we can create a test Adobe Admin Account, as I'm uncertain Adobe allow for this. I've tried to use the SingleFile extension to see if I can create an offline version of the page which can replicate the issue but no such luck.

If it helps I've attached the markup for the parts of the 3 pages demonstrating the issue. Forgive me if this is not helpful, but I'm just not sure I'm going to get anywhere with Adobe.

Comment 11

[oneofthedamons]

Attachment: div Overview.html

Comment 12

[oneofthedamons]

Attachment: div Products.html

Comment 13

[oneofthedamons]

Attachment: div Packages.html

Comment 14

[Mayank Bansal]

Thanks for the bisection. I am marking dependency on bug 1768921.. . Since this bug has landed, couple of fixes for regression have also landed. Could you also test the latest Firefox Nightly to see if one of those regression-fixes also fix your issue?
(I checked with the latest Nightly and Chrome, and all the three testcases you attached look about the same)

Comment 15

[Mayank Bansal]

Attachment: Firefox Nightly Vs Chrome.png

How your 3 testcases look on Firefox Nightly Vs Chrome

Comment 16

[Mayank Bansal]

needinfo for comment #14

Comment 17

[Emilio Cobos Álvarez [:emilio]]

[Tracking Requested - why for this release]:

Comment 18

[Emilio Cobos Álvarez [:emilio]]

Could you use https://addons.mozilla.org/en-US/firefox/addon/testcase-reducer/ to reduce a test-case with all the relevant CSS?

Inspect an element with right click -> Inspect, go to the Testcase Reducer tab, and click reduce. It should hopefully reproduce the issue.

Comment 19

[oneofthedamons]

Regarding comment #14 this is not fixed on Firefox Nightly 135.0a1 (2024-12-09) BuildID 20241209143224

Comment 20

[oneofthedamons]

(In reply to oneofthedamons from comment #19)

Regarding comment #14 this is not fixed on Firefox Nightly 135.0a1 (2024-12-09) BuildID 20241209143224

Sorry please ignore this! The issue is RESOLVED in Firefox Nightly 135.0a1 (2024-12-09) BuildID 20241209143224

(That will teach me to get coffee and Bugzilla in the wrong order…)

Thanks for your assistance!

Comment 21

[oneofthedamons]

Regarding comment #18 :emilio do you still need me to use testcase-reducer is that redundant now?

Comment 22

[Emilio Cobos Álvarez [:emilio]]

Would be useful, to make sure we don't regress it in the future.

Comment 23

[Daniel Holbert [:dholbert]]

We've also got someone internally who's got access to this Adobe UI who might be able to get a testcase (David found someone on Slack), so we might be able to sort this out internally -- but it's after-hours for all of the involved folks at the moment so I'm not entirely sure if they've gotten a testcase or were able to successfully reproduce the bug on their end. :) So: if you happen to be able to generate a testcase using testcase-reducer, that'd still be helpful, but no worries if you're not able to or if Testcase Reducer falls over and doesn't produce a workable tetscase (it's not perfect & doesn't handle all edge cases).

Comment 24

[Ryan VanderMeulen [:RyanVM]]

Bug 1934960 is the only regression from bug 1768921 which is fixed for 135 but hasn't been backported to 134 yet, so if current Beta is still reproducing the problem, that could be what fixed Nightly (I can't tell what I'm supposed to be seeing with the attached testcases or I'd try to bisect the fix myself).

Comment 25

[oneofthedamons]

Attachment: Testcase reduced Overview.html

Comment 26

[oneofthedamons]

Attachment: Testcase reduced Products.html

Comment 27

[oneofthedamons]

Attachment: Testcase reduced Packages.html

Comment 28

[oneofthedamons]

Emilio Cobos Álvarez (:emilio) & Daniel Holbert [:dholbert] I have uploaded the Testcase reduced HTML, hopefully I managed to do this correctly. Please let me know if not.

Comment 29

[Daniel Holbert [:dholbert]]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #24)

Bug 1934960 is the only regression from bug 1768921 which is fixed for 135 but hasn't been backported to 134 yet, so if current Beta is still reproducing the problem, that could be what fixed Nightly

Yeah, I would also bet that was what fixed this.

(I can't tell what I'm supposed to be seeing with the attached testcases or I'd try to bisect the fix myself).

I don't think we have a testcase that reproduces the issue yet -- or rather, we have testcases that render kinda-bad results but not in a way that's specific to the broken Firefox versions here. [please correct me if I'm wrong]

Comment 30

[Daniel Holbert [:dholbert]]

(In reply to oneofthedamons from comment #28)

Emilio Cobos Álvarez (:emilio) & Daniel Holbert [:dholbert] I have uploaded the Testcase reduced HTML, hopefully I managed to do this correctly. Please let me know if not.

Thank you very much for taking the time to do that! It looks like you probably did everything correctly, but Testcase Reducer itself seems to have not been able to quite capture the issue -- or maybe it captured the issue too well. :) The markup that it generated seems to be similarly-broken in Firefox 134 Beta, Firefox 135 Nightly, and Chrome, so it's unfortunately not useful for verifying which build(s) are good vs. bad. (That might have happened for a variety of reasons. My guess would be that Adobe is doing something dynamic and fancy, and the issue happens early-on in the life cycle of that fanciness -- and by the time you nudge Testcase Reducer to save the page-content, it's already too late and the page-content is unconditionally broken, so you get an unconditionally broken result.)

The most valuable remaining thing that remains to be done right now is to verify that bug 1934960's patch is indeed what fixed this (which is what RyanVM was alluding to wanting to do himself if he could only reproduce). That bug's patch landed in our main repository on Dec 5th, so as far as mozregression is concerned, that would mean that 2024-12-04 should be "bad" and 2024-12-06 should be "good". (Maybe 2024-12-05 would be "good" too, but I don't know offhand what the first commit was that made it into the 12/5 Nightly, so let's round up by a day and start with 12/06 as a candidate "good" build to be safe.)

Since you enjoyed your mozregression experience in comment 10 :) perhaps you'd be willing to use it once more to validate the above theory? (to confirm that 2024-12-04 is "bad" and 2024-12-06 is "good") If you're up for that: you can do that in mozregression-gui with File-menu | Run a Single Build (or from the command line with mozregression --launch 2024-12-04 for example). And if that theory checks out: I think we can be pretty sure about the fix, but bonus points if you can bisect in that range to further-confirm the fix with a narrowed pushlog, by putting those dates into mozregression-gui with the checkbox for "search for a bug fix instead of a regression" checked (below the good/bad dates), or with e.g. mozregression --find-fix --bad 2024-12-04 --good 2024-12-06 if you're using the command line.

No worries if that's too much to ask, though. Thanks again for the bug report!

Comment 31

[BugBot [:suhaib / :marco/ :calixte]]

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.

Comment 32

[BugBot [:suhaib / :marco/ :calixte]]

The bug is marked as tracked for firefox134 (beta) and tracked for firefox135 (nightly). However, the bug still isn't assigned.

:fgriffith, 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 33

[Daniel Holbert [:dholbert]]

(closing to silence bugbot, since this is fixed per comment 20. Only remaining task here is confirming what fixed it, so we can be sure beta is also fixed.)

Comment 34

[Frank Griffith Jr]

bugbot has no respect for the review cycle......

Comment 35

[David Shin[:dshin] (PTO Til 24th)]

Ok.. I was coordinating internally for bisecting this, and Adobe did not like multiple (Successful) log-in attempts, so we couldn't narrow down completely. However, it was indicating that the fix happened between 12-01 and 12-04, which is unexpected.
Looking through pushlog - One bug that stands out in any way to me is Bug 1931490. I do see contain: size layout style; present in inline styles for table-related elements, so that could explain it?
Hypothesis is that pre-Bug 1768921, we relied on ConsiderBlockEndEdgeOfChildren for block-direction scroll overflow, effectively covering this issue)

Comment 36

[oneofthedamons]

I confirm when I performed mozregression as requested in comment #30 the result identified Bug 1931490 pushlog_url https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=e40127bbcf117ac32421551a549b9f0e3f933c02&tochange=a16037ec6ad2bde99ca422bc029b0ab4804a1682

Comment 37

[Ryan VanderMeulen [:RyanVM]]

This will be fixed in the Firefox 134 release shipping on January 7.