1914395 - adobe.com - Footer overlaps with "Get help signing in" button on the login page

Status: RESOLVED FIXED

(Web Compatibility :: Site Reports, defect, P1)

Description

[Calin Tanase]

Attachment: image.png

Environment:
Operating system: OnePlus 6 A6000 (Android 11)
Firefox version: Nightly 131.0a1-20240820095153

Steps to reproduce:

1. Go to https://www.adobe.com
2. If prompted select the US website.
3. Dismiss the cookie banner.
4. Tap on the "Sign in" button.
5. Observe the footer.

Expected Behavior:
The footer is displayed correctly.

Actual Behavior:
The footer overlaps with "Get help signing in" button.

Notes:

1. Screenshot attached
2. Reproducible regardless of the ETP status
3. Not reproducible on Firefox Release and Chrome
4. Might be related with the implementation of the new toolbar
5. Issue found during WebCompat team [Top100] websites testing

Comment 1

[Alice0775 White]

If the width of the browser was minimized and the height was also reduced, then I can reproduce the issue on Nightly132.0a1 Windows11 and also on Firefox68.0 Windows11.

Comment 2

[Jeff Muizelaar [:jrmuizel]]

Alice, can you still reproduce this on Windows? I wasn't able to.

Comment 3

[Alice0775 White]

I can still reproduce the issue on Nightly132.0a1(20240904095513) Windows11.

Screencast: https://youtu.be/LSQAJWRA5MY

Comment 4

[Jeff Muizelaar [:jrmuizel]]

It seems like the "For your protection, please verify your identity." bar is needed for it to show up and clicking "sign in" at the top doesn't give that but clicking on "Log in to your account" does.

Comment 5

[Jeff Muizelaar [:jrmuizel]]

Attachment: Standalone test case

Load the attached test case in Chrome and Firefox in responsive design mode and set the dimensions to 400x700. In Chrome things are scrollable in Firefox they overlap

Comment 6

[Jeff Muizelaar [:jrmuizel]]

Daniel, can you take a look at what might be going on here?

Comment 7

[Daniel Holbert [:dholbert]]

Looks like a bug in our grid code; possibly a spec change that we've got yet-to-implement. I spun off bug 1916849 with a reduced testcase.

Comment 8

[Mike Conley (:mconley) (:⚙️) (PTO Dec 22 - Jan 2)]

Hey dholbert, asking here rather than bug 1916849 for ease of tracking - have we made any progress on identifying what we might need to do differently here, and how expensive that work is? Is this something that could be reasonably and safely fixed for 131 (currently beta), or should we just accept this defect for 131?

Comment 9

[Daniel Holbert [:dholbert]]

No one's actively poking beyond the testcase-reducing/bug-spin-off work that I already did here.

We've got a few folks working on grid interop-2024 bugs at the moment, and I think there's a good bet that this will be fixed by part of that work (or conversely, that fixing bug 1916849 will get us passing some existing interop-relevant WPTs that we're currently failing).

I'll bring up bug 1916849 in my next meeting with those folks, which is tomorrow.

Comment 10

[Daniel Holbert [:dholbert]]

but yeah, for 131 specifically, I think this is WONTFIX. The fix here will likely carry some risk.

Comment 11

[Donal Meehan [:dmeehan]]

(In reply to Daniel Holbert [:dholbert] from comment #9)

No one's actively poking beyond the testcase-reducing/bug-spin-off work that I already did here.

We've got a few folks working on grid interop-2024 bugs at the moment, and I think there's a good bet that this will be fixed by part of that work (or conversely, that fixing bug 1916849 will get us passing some existing interop-relevant WPTs that we're currently failing).

I'll bring up bug 1916849 in my next meeting with those folks, which is tomorrow.

Any updates on this? Wondering if something can be expected for Fx134?

Comment 12

[Daniel Holbert [:dholbert]]

Emily's got a work-in-progress patch posted on the linked bug. Seems like it might make it for 134, but I'm not entirely sure.

Comment 13

[Pascal Chevrel:pascalc]

Emily, have your patches in bug 1931594 an effect on this bug or do we also need bug 1932025 to mark this one as fixed? Thanks

Comment 14

[Emily McDonough [:alaskanemily]]

Based on how the changes have been broken up, the actual change that still affects this is Bug 1916849.

Comment 15

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 (adapted from standalone to test the bug regardless of viewport size)

To make retesting a bit easier, here's the standalone test case, now with styles tweaked so that it's testing the buggy scenario regardless of what your browser's viewport size happens to be.

(The previous testcase was nice and responsive which meant it required a particular viewport-size in order to repro the bug.)

Comment 16

[Daniel Holbert [:dholbert]]

Attachment: screenshot showing the bug (Firefox on left, Chrome on the right)

(for future retesting: here's how the bug currently looks with the just-attached testcase 2. Firefox on left has the content much more cramped vs. Chrome on the right, and we also have the "verify your identity" blurb pushed off the top of the viewport.)

Comment 17

[Ryan VanderMeulen [:RyanVM]]

Was this fixed by bug 1916849?

Comment 18

[Daniel Holbert [:dholbert]]

Attachment: screenshot comparing Nightly 2024-12-19 (left) vs 2024-12-20 (right) on testcase 2

Yeah, I think this was fixed by bug 1916849. Here's testcase 2 before/after the patch for bug 1916849 landed. Note that "before" has some content clipped at the top, and content near the bottom pushed to overlap or nearly overlap, whereas the right doesn't have content clipped at the top, and we're not squishing things to overlap. (matching the Chrome rendering on the right side of comment 16).

Comment 19

[Daniel Holbert [:dholbert]]

Note, the actual Adobe login page looks a little different from testcase 2 now -- in particular the "For your protection" blue-section at the top is no longer present on the live site now, for me at least. (I guess that wasn't present in the screenshots in comment 0 either.)

But anyway, I think this is fixed on the live site, too -- I see a rendering difference there between Fenix release and nightly, with Nightly looking similar to Chrome. (I'm testing both builds with the same navbar-disabled configuration using secret-settings to make it an apples-to-apples comparison.)

Specifically: on the live site, in Chrome and current Firefox Nightly, there's some breathing room (maybe 1-2 line-heights-worth of space) between the "chat" button at the bottom-right and the separator-bar for the footer links. In Release 134, there's barely any space between that button and the separator line. (The layout is highly dependent on your device characteristics, I think (screen resolution, fonts, etc), so other folks might see more obvious overlap in release like in comment 0 here and the difference might be more pronounced.)

Comment 20

[Daniel Holbert [:dholbert]]

(Note: for webcompat site-report bugs, I think we currently default to leaving the bug in an "open" state until the fix hits release, which is admittedly slightly awkward vs our regular bugzilla workflows. But it doesn't much matter. Can discuss more in #webcompat on slack to avoid derailing this bug. :)

Also notably, we'll likely be soon landing a behavior change to bug 1916849's code, to address the regression that it introduced (bug 1938619). Or, if we don't have a fix soon, we may need to backout bug 1916849 on beta 135. So: tracking flags here may need an update in the near future to match reality, depending on what happens there.)

Comment 21

[Ryan VanderMeulen [:RyanVM]]

To your point, bug 1916849 was backed out for 135.0b5. Updating the flags accordingly.

Comment 22

[Daniel Holbert [:dholbert]]

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

To your point, bug 1916849 was backed out for 135.0b5. Updating the flags accordingly.

And during the Nightly 136 cycle, we put the "good behavior" behind an off-by-default pref, due to regressions (which we need to fix before enabling the pref), in bug 1938619.

So: this is not in fact fixed on Nightly or on any branches. --> Reopening.

Comment 23

[Daniel Holbert [:dholbert]]

note: to trigger overlap exactly-as-shown-in comment 0, you need a somewhat-small screen size. (As an example, my Pixel 6a doesn't hit the overlap there.)

But you can also see this bug still reproducing even on a larger-screen device if you tap the "View more" link below the list of sign-in options; I'll post screenshots showing what that breakage looks like.

Comment 24

[Daniel Holbert [:dholbert]]

Attachment: screenshot comparing Nightly 138.0a1 2025-03-10 (left) vs. Chrome (right) after clicking "View more"

you can also see this bug still reproducing even on a larger-screen device if you tap the "View more" link below the list of sign-in options; I'll post screenshots showing what that breakage looks like.

Here's a screenshot [edit: screenshot is in my next comment] showing this. See Firefox on the left side here, doing two bad things:
(1) pushing the header (currently with "Adobe" logo) off the top of the screen, making it unscrollable (note, sometimes there's more-important-than-just-a-logo text that gets pushed out of view here, as in comment 18's screenshot)

(2) placing the login-provider-buttons superimposed with the footer-text ("Copyright 2025 Adobe" etc). (You can't see that footer-text in the Chrome right-hand portion of my screenshot; take my word for it that it's just offscreen, and nicely visible if you scroll down.)

If I toggle the aforementioned off-by-default pref (layout.css.grid-flex-spanning-items-intrinsic-sizing.enabled) to true, then we change to the expected results here, fully matching Chrome's layout shown on the right on both of these^ points.

Comment 25

[Daniel Holbert [:dholbert]]

Attachment: screenshot comparing Nightly 138.0a1 2025-03-10 (left) vs. Chrome (right) after clicking "View more"

(sorry, I attached the wrong screenshot there. Here's the side-by-side comparison that I meant to attach.)

Comment 26

[Daniel Holbert [:dholbert]]

Note: we need a new platform-bug for this bug to depend on here -- right now at least, this is marked as depending on a platform bug that's been closed (for reasons discussed in comment 22), which puts it in a slightly confusing/inconsistent state for a successfully-diagnosed WebCompat Site Report bug.

This bug should depend on whatever bug we intend to use to toggle the aforementioned pref (or do something that has the same effect, e.g. removing the pref entirely with only the good behavior remaining, or something else with that same good-behavior outcome). In other words, this should depend on whatever bug is the answer to my question in bug 1951817 comment 1.

Emily: could you add whatever the right bug is, to the "Depends on" field for this bug here?

Comment 27

[Emily McDonough [:alaskanemily]]

This depends on fixing bug 1955109 which I am looking into currently.

Comment 29

[Emily McDonough [:alaskanemily]]

With bug 1955109 landing, this should be fixed when the pref layout.css.grid-flex-spanning-items-intrinsic-sizing.enabled is set to true.
This pref was flipped on for nightly only in that same bug. We were quite late in the cycle when that landed, and I want more testing in nightly before unconditionally flipping on the pref.
Barring any major issues, I plan to set the pref to true and let it ride the trains in Firefox 139. See bug 1956610 for flipping on the pref on all channels.

Comment 30

[Calin Tanase]

Retriaged, the issue no longer reproduces on the latest Nightly (139.0a1-20250412090848). Marking this as fixed.