1928954 - publix.com - Blank page is displayed when clicking on the "Delivery and curbside" button

Status: REOPENED

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

Description

[ioanidapop]

Attachment: blank_page_issue.mp4

Environment:
Operating system: Windows 10
Firefox version: Firefox 132.0 (release)/134

Preconditions:

• Clean profile

Steps to reproduce:

1. Navigate to: https://www.publix.com/?utm_medium=maps&utm_source=extendednetwork&utm_content=psm_website_url
2. Click on the "Delivery and curbside" button
3. Observe the behavior

Expected Behavior:
The Delivery and curbside page is displayed. https://delivery.publix.com/store/publix/storefront

Actual Behavior:
A blank page is displayed.

Notes:

• Reproducible on the latest Firefox Release and Nightly
• Reproducible regardless of the ETP setting
• Works as expected using Chrome

---

Created from webcompat-user-report:0b9e5b6d-97a6-4291-85fa-ecc54d070a96

Comment 1

[Dennis Schubert [:denschub]]

Needs a US VPN to test.

Comment 2

[Daniel Holbert [:dholbert]]

I can reproduce.

In Chrome, I see a popup notification saying "Leaving publix.com".
In Firefox, I briefly see that popup notification, and then I end up being redirected immediately to a plain-text document that just says "7" or "10".

Comment 3

[Daniel Holbert [:dholbert]]

A few more observations:

• Chrome mask doesn't help; I can still repro in Firefox with Chrome Mask turned on for this site.
• I can reproduce in Nightly 2021-11-01 96.0a1, so this isn't a regression on our end (or not a recent one).
• When I load the web page here (before I click anything), the web console shows Uncaught (in promise) DOMException: The operation is insecure. for something in "up_loader", but that goes away if I disable ETP (but the bug remains even with ETP off); so that's unrelated to this bug.
• Web Console does show two cookie errors there, though:

Cookie “optimizelyOptOut” has been rejected for invalid domain.
Cookie “s_ac” has been rejected for invalid domain.Cookie “s_ac” has been rejected for invalid domain.

I don't see those in Chrome's web console, so maybe it's conceivable they're related?

I found one spot where I can sort-of hook in in the debugger just before the page disappears -- you can place a breakpoint on the "y.disconnect" line here, in the beforeunload handler:
https://assets.adobedtm.com/6262187ff74a/e03fc5c503a5/launch-1bddd4271e00.min.js

              i.addEventListener(
                'beforeunload',
                (function () {
                  y.disconnect(),
                  i.clearInterval(e)
                }),

(That's not necessarily super useful because it doesn't tell you why we're unloading, but it's just a step removed from answering that question...)

Comment 4

[Daniel Holbert [:dholbert]]

Here's a performance profile which might have some clues:
https://share.firefox.dev/4hHZcMs

Here's a zoomed in portion showing the section where I click and we go blank:
https://share.firefox.dev/3O0y913

In the marker chart there, in the "DOMEvent" track, you can see the click followed by various teardown-related events like "beforeunload", "pagehide"... I'm not 100% sure that those are associated with our switch to the blank page here (vs. the switch to showing the popup), but they might be.

Comment 5

[Daniel Holbert [:dholbert]]

Also interesting: if I hover the link, it shows the link target as:
javascript:EventBus.$emit('InstacartRedirectModal.requestOpen'); window.adobeDataLayer.push({'event': 'header_click', 'context': 'hdr_delivery_&_curbside'});

If I copypaste that string (minus the leading javascript:) into my Web Console and hit Enter, then I get EXPECTED RESULTS -- the "Leaving publix.com" popup appears, and I can click through it to land on their delivery site.

So that JS does the right thing when I directly execute it, but it's triggering badness when executed via a click for some reason.

Bumping this over to the DOM team's diagnosis-queue at this point - this feels like something with DOM event handling and/or page-navigation-lifecycle-related perhaps. Hoping someone there has cycles to pick this up. Thanks!

Comment 6

[Sean Feng [:sefeng211]]

This comes down to how we handle href="javascript:.." differently than Chrome.

data:text/html,<a href="javascript:6">Click me</a> will cause a navigation in Firefox, but it doesn't do anything in Chrome.

We thought the returned value was a string, hence a navigation happened afterwards.

This looks like a platform bug, because it returns an integer? Not sure this is a DOM bug or JS bug, and I'd like to double check with the Spidermonkey team so passing this over. Please feel free to pass this back!

Comment 7

[Daniel Holbert [:dholbert]]

(In reply to Sean Feng [:sefeng] from comment #6)

This comes down to how we handle href="javascript:.." differently than Chrome.

data:text/html,<a href="javascript:6">Click me</a> will cause a navigation in Firefox, but it doesn't do anything in Chrome.

Thanks! That's a good insight. I think we can consider this "diagnosed" as that^ exact difference, and spin off a platform bug to cover that (I'll do that now).

Comment 8

[Daniel Holbert [:dholbert]]

(restoring diagnosis-team:dom since sefeng diagnosed this on behalf of dom folks; we can engage in discussion about correctness/further-diagnosis over on the platform bug which is bug 1931058.)

Comment 9

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

Since nightly and release are affected, beta will likely be affected too.
For more information, please visit BugBot documentation.

Comment 10

[Jeff Muizelaar [:jrmuizel]]

Now that bug 1931058 has landed I can no longer reproduce this in Nightly but can in release. Marking as fixed.

Comment 11

[Thomas Wisniewski [:twisniewski]]

Attachment: Bug 1928954 - add a JS intervention to prevent link breakage on publix.com; r?denschub

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f5e91cc8498c
add a JS intervention to prevent link breakage on publix.com; r=denschub,webcompat-reviewers

Comment 13

[Cosmin Sabou [:CosminS]]

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

Comment 14

[Thomas Wisniewski [:twisniewski]]

Bug 1931058 just landed, so we can adjust the intervention to only be active on Firefox versions under 140. But since it's harmless to keep the intervention around, let's wait until we've confirmed that the patch in bug 1931058 is actually going to ship.

Comment 15

[Thomas Wisniewski [:twisniewski]]

Attachment: Bug 1928954 - disable the webcompat intervention for publix.com on version 140 and up, where it's no longer needed; r?denschub

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/e945405ed3bb
https://hg.mozilla.org/integration/autoland/rev/3139ae19a609
disable the webcompat intervention for publix.com on version 140 and up, where it's no longer needed; r=denschub,webcompat-reviewers

Comment 17

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/3139ae19a609

Comment 18

[Kagami Rosylight [:saschanaz] (they/them)]

Does comment #16 mean this can be closed?

Comment 19

[Thomas Wisniewski [:twisniewski]]

We're still shipping an intervention for earlier ESR builds, so I was keeping the bug open for tracking purposes But I don't mind closing it if we'd rather do so?

Comment 20

[Kagami Rosylight [:saschanaz] (they/them)]

Either way is fine, just asking because I discovered this bug in needs-diagnosis backlog (it doesn't need diagnosis so idk why it lists this one)