1946409 - www.lush.com - The page does not respond after accessing it

Status: ASSIGNED

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

Description

[Raul Bucata]

Environment:
Operating system: Android 14
Firefox version: Firefox Mobile 134.0

Steps to reproduce:

1. Navigate to: https://www.lush.com/uk/en/p/spa-party-voucher?lid=egw4ypu4tl11&utm_source=newsletter&utm_medium=email&utm_campaign=UK_SpaPartiesAndSpa_300125
2. Attempt any action on the page and observe

Expected Behavior:
The page responds

Actual Behavior:
The page does nothing

Notes:

• Reproduces regardless of the status of ETP
• Does not reproduce in firefox-nightly, firefox-release, and chrome
• Does not reproduce in Private Mode

Created from https://github.com/webcompat/web-bugs/issues/147859

Comment 1

[Raul Bucata]

This might be caused by the cookie policy not being triggered in Firefox Focus

Comment 2

[Raul Bucata]

Attachment: focus vs nightly (private and normal)

Comment 3

[Mihai Adrian Carare [:mcarare]]

After the page is loaded there is a cookie banner that does not adapt to mobile version that actually covers the webpage content.
If you switch to desktop mode or zoom out the page, you can see it and and save cookie preference and interact with the page.
On my device ( Android 14 Pixel 4) I can reproduce it in latest Firefox mobile release and in Fenix Nightly in both private mode and normal browsing.

Comment 4

[Raul Bucata]

I have no idea what my first comment was duplicated later, apologies for that

Comment 5

[Raul Bucata]

The cookie banner for me is present in Private and Normal mode in the view port, even if it is slightly cropped. In Focus, the cookie banner is not presented inside the viewport, not even cropped. But yes, zooming out solves the issue in Focus (which is not required in Fenix)

Comment 6

[Mihai Adrian Carare [:mcarare]]

On my devices (Android 9 and Android 13), the banner shows up in Fenix the same way it shows up in Focus.

Comment 7

[Mihai Adrian Carare [:mcarare]]

Adding QA so they can test Fenix on more devices to see if this needs to be moved to the Fenix product. Thank you!

Comment 8

[Mira Lobontiu (Android QA)]

I can confirm that the https://www.lush.com/uk/en/p/spa-party-voucher?lid=egw4ypu4tl11&utm_source=newsletter&utm_medium=email&utm_campaign=UK_SpaPartiesAndSpa_300125 page is unresponsive in Fenix 135.0, and Fenix Nightly 137.0a1, in both private and normal mode.
In normal mode you can accept the cookies from the prompt, but then it is really hard to navigate the website.
In private mode is much worse, the cookie prompt is not displayed, but the page is totally unresponsive.

Tested with a Xiaomi Mi8 Lite (Android 10), and a OnePlus 5 (Android 10).

On a Pixel 6 (Android 15) the page is unresponsive in both normal and private mode.

Comment 9

[Mihai Adrian Carare [:mcarare]]

Moving this to the Fenix product for further investigations. Reintroducing the issue into triage by removing its severity.

Comment 10

[Sky Schubert [:skyschub]]

Looks like this is just a WebCompat bug, not a Fenix product issue (yet). Let's have the Layout team look at the cookie banner that's blocking the site.

Comment 11

[Daniel Holbert [:dholbert]]

Attachment: screenshot of bug in Responsive Design Mode in Firefox (left) vs Chrome (right)

The Firefox/Chrome beahvior-difference reproduces in RDM on desktop too (using Galaxy S20 Ultra as the RDM profile).

The site is unusable in Firefox since the cookie banner is casting an overlay on the page but the cookie-banner-buttons are all offscreen; whereas it's usable (albeit cosmetically not-great) in Chrome.

Comment 12

[Daniel Holbert [:dholbert]]

Moving this over to APZ team for triage since they're closer to the Android mobile-viewport code.

(This reminds me slightly of bug 1911457, but of course it's not exactly the same since bug 1911457 was fixed.)

Comment 13

[Hiroyuki Ikezoe (:hiro)]

So a primary question here is that how Chrome renders the page. I am pretty sure I got the same rendering result as the screenshot Daniel posted in comment 11. But (probably) once after I closed the cookie banner and cleared out the cookie data, then I've gotten the same result of Firefox.

FWIW, I tested it on Chrome's RDM mode.

Comment 14

[Hiroyuki Ikezoe (:hiro)]

Attachment: A screenshot on Chrome RDM

Okay, reloading the page resulted a different result.

Attaching file is a screenshot on Chrome RDM.

It looks to me that the viewport size is same as Firefox, but a different point is on Chrome it scrolls to the cookie banner.

Comment 15

[Hiroyuki Ikezoe (:hiro)]

I am not (yet) sure what the differences between Chrome and Firefox are. On Chrome it looks like the site does invoke a scrollIntoView call for the cookie banner. But on Firefox scrollIntoView for the cookie banner doesn't work. I filed bug 1951021.

Though, if I am debugging correctly, I don't see any scrollIntoView calls on Firefox.

Comment 16

[Hiroyuki Ikezoe (:hiro)]

(In reply to Hiroyuki Ikezoe (:hiro) from comment #15)

I am not (yet) sure what the differences between Chrome and Firefox are. On Chrome it looks like the site does invoke a scrollIntoView call for the cookie banner. But on Firefox scrollIntoView for the cookie banner doesn't work. I filed bug 1951021.

Though, if I am debugging correctly, I don't see any scrollIntoView calls on Firefox.

It turned out that the scroll operation is a part of focus(). The site calls Element.focus() for the "Accept all cookies" element, but at that time the cookie banner #portal-cookie-banner__content has "transform: translate3d(0, 100% ,0)" style (with "position:fixed; bottom: 0"), thus the banner is not visible in the layout viewport at all, thus scroll operation does nothing. This also happens on Chrome as I observed in comment 13.

The cookie banner is animated by changing the transform style, you can observe the animation on desktop, and on Chrome reloading the content seems to trigger the transform style changes earlier than the focus call, then the banner can be scrolled into view.

I am going to stop further diagnosis here since I can no longer see the viewport size difference on my end.

Comment 17

[Hiroyuki Ikezoe (:hiro)]

I tested the site on mobile Chrome. On my pixel3, the rendering result is same as on Chrome RDM, i.e. the cookie banner is scrolled into view, the viewport size looks same as on Firefox.

Maybe the site has changed something?

Comment 18

[Hiroyuki Ikezoe (:hiro)]

I don't see the viewport difference on mobile Chrome even on any new tab. I am seeing the same result as the screenshot in comment 14.

Comment 19

[Randell Jesup [:jesup] (needinfo me)]

Hiro - does that mean this bug is WorksForMe now?

Comment 20

[Daniel Holbert [:dholbert]]

Attachment: screencast showing the bug reproducing with Nightly 2025-03-23, vs. Chrome not-reproducing, on Pixel 6a

Nope, this is in fact still broken. Here's a screencast comparing latest Android Nightly available in Play store (2025-03-23) to Chrome on my Pixel 6a.

Summing up the current state of things, testing in a fresh profile + new tab in both Firefox Nightly and Chrome: when the gray overlay appears (indicating that a cookie banner has been added to the page):

• Chrome scrolls vertically to show the cookie banner + buttons (or at least the left half of it), and the user can dismiss the banner.
• Firefox does not scroll to show the cookie banner.

When the overlay/banner are present, neither browser lets the user scroll manually (i.e. touching and dragging up/down has no effect, even in Chrome where the browser scrolls on your behalf to show the banner). But both browsers do let you pinch-zoom out (per comment 3), which then reveals the full cookie banner in both browsers. This pinch-zooming is sort of a workaround for the issue, but it's not an obvious one; there's no way for the user to know that zooming out is a useful thing to do when loading this site, since they don't know that the cookie banner is just-offscreen.

(Also, for what it's worth: in Firefox on my (larger-screen) Pixel 9 Pro XL, the top line of text from the cookie banner is barely visible on-screen, but you still can't reach any of the buttons.)

Comment 21

[Hiroyuki Ikezoe (:hiro)]

(In reply to Randell Jesup [:jesup] (needinfo me) from comment #19)

Hiro - does that mean this bug is WorksForMe now?

No.

After comment 18, Daniel noticed me that the site can be pinch-zoomed in manually and the minimum-scale size is different between Chrome and Firefox.

Unfortunately I haven't haven time on this for now, so there's no progress I can tell.

Comment 22

[railioaie]

The issue is still reproducible

Tested with:

Browser / Version: Firefox Focus Nightly 138.0a1 (390831145-🦎138.0a1-20250324091950🦎)
Operating System: Android 11

Comment 23

[Hiroyuki Ikezoe (:hiro)]

Attachment: A replica of the viewport difference?

I would think attaching file is a replicated test case for the viewport difference.

It's rendered in 1.0x scale on Firefox RDM and on Chrome RDM. But it's scaled by < 1.0 on Chrome mobile.

I have no idea where the difference comes from.

At least on Firefox RDM (and mobile), the test case has <meta name="viewport" content="width=device-width,initial-scale=1"> so that it's scaled by 1.0x.

Comment 24

[Hiroyuki Ikezoe (:hiro)]

I tried the test case in comment 23 on mobile Safari, it doesn't scaled at all. So in term of the viewport, I would say our behavior is correct.

That's being said, on mobile Safari the cookie banner is slid in.

To summarize what I've observed

On mobile Chrome

1. the content is scaled down even though there's initial-scale=1 (it smells like a bug in Chrome)
2. the cookie banner is slid in for some reasons

On mobile Safari

1. the content is NOT scaled down
2. the cookie banner is slid in for some reasons

On mobile Firefox

1. the content is NOT scaled down
2. the cookie banner is NOT slid in because the banner is totally outside of the layout viewport due to translate3d(0, 100% ,0).

Comment 25

[Hiroyuki Ikezoe (:hiro)]

Attachment: A replica of scroll-to-banner differences

I think this test case is kinda replicating the scroll-to-banner differences.

There's an element whose transform style value is translate3d(0px, 100%, 0px).

Mobile Chrome does scroll to the banner even though the element is not visible at all

Mobile Safari does NOT scroll to the banner.
Mobile Firefox does NOT scroll to the banner.

I would say, the Chrome's behavior is a bug though, I should read the spec.

Comment 26

[Hiroyuki Ikezoe (:hiro)]

Filed a chromium bug; https://issues.chromium.org/issues/407801070

Comment 27

[Hiroyuki Ikezoe (:hiro)]

I think;

  #portal-cookie-banner__content {
    top: 0px;
  }

would be an intervention for this specific site. Though it would look ugly because the banner will be laid out at the top of the page.

Another intervention I can think of is to inject an additional meta viewport tag without "initial-scale=1" such as <meta name="viewport" content="device-width"> after the original meta viewport tag has been loaded. With this way, the result should look same as mobile Chrome.

I think I've done diagnosis as a member of APZ team, I am removing "diagnosis-team:apz" and "webcompat:needs-diagnosis".

Comment 28

[Hiroyuki Ikezoe (:hiro)]

In the chromium bug, a chrome developer (maybe flackr?) convinced me that it's intentional, it's not a bug.

A relevant part of the behavior in the spec is, I think, here in 6.1. Element Scrolling Members section specifically;

10. Let position be the scroll position scrolling box would have by following these steps:
    1. If block is "start", then align element edge A with scrolling box edge A.

It doesn't care whether the element is outside of the scroll range or not. So the chrome developer is right, the chrome behavior matches the spec text.

This fact realized me that the way we fixed bug 1947223 is quite wrong, and realized me that the site (https://school.moodledemo.net/course/view.php?id=56) in bug 1947223 doesn't work well on mobile Chrome if the user pinch zoomed in the site because Chrome scrolls to unreachable element. :/

Anyways, in short we can't fix both bug 1947223 and this bug altogether. From the perspective of the spec definitions, the moodledemo site needs to be changed.

Comment 29

[Thomas Wisniewski [:twisniewski]]

Changing the meta-viewport gives us a different layout than Chrome, under the cookie banner, but this CSS seems to work fine and match their intent (their bottom:0 on the cookie banner content), so I'm going to use it instead:

#portal-cookie-banner__wrapper { height:100vh; }
#portal-cookie-banner__content { position:absolute; }

Comment 30

[Thomas Wisniewski [:twisniewski]]

Oh right, on an actual device, using vh units will not take the address bar into consideration, so the banner will end up sneaking under it, covering up the bottom button. So I'll also add padding-bottom: 50px under that button to compensate.

Comment 31

[Thomas Wisniewski [:twisniewski]]

Attachment: Bug 1946409 - add an Android-only CSS webcompat intervention for www.lush.com to un-hide their cookie banner popup; r?denschub

Comment 32

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/0eea311a0e2e
https://hg.mozilla.org/integration/autoland/rev/f496e66670af
add an Android-only CSS webcompat intervention for www.lush.com to un-hide their cookie banner popup; r=denschub,webcompat-reviewers

Comment 33

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/f496e66670af