1605556 - Movie showtimes links don’t work in Google results in Firefox

Status: RESOLVED WORKSFORME

(Core :: DOM: Navigation, defect, P2)

Description

[stansult]

Attachment: Firefox.jpg

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:71.0) Gecko/20100101 Firefox/71.0

Steps to reproduce:

1. Google search: “star wars tickets” in Firefox (on Mac)
2. In the showtimes widget (title: “Showtimes for Star Wars: The Rise of Skywalker”), click any showtime (e.g. Today, 9:40 pm in Regal Foothill Towne Center)
3. In the “Buy tickets” popup that opens, click any of the options (e.g. Fandango)

Actual results:

Same page reloads

Expected results:

Fandango website should open, loading movie ticket checkout page for the showtime selected

Comment 1

[Virginia (please send need info request to Brindusa Tot)]

Hi stansult,

Thanks for reporting this bug.

I was able to reproduce it on Mac OSX 10.15 on the following firefox versions:

• Nightly 73.0a1 (2019-12-26)
• Beta 72.0b11
• Release 71.0

I will add this issue a component and hopefully their team will look it over and advise.

Web Compatibility: Desktop team: If you consider there's a more appropriate product/component for this issue, feel free to change it.

Regards,
Virginia

Comment 2

[Patrick (he/him)]

I have also been able to reproduce this bug on Windows 10, on:

• Nightly 73.0a1 (2019-12-30)
• Beta 72.0b11

Comment 3

[Patrick (he/him)]

Also able to reproduce in Release 71 on Windows 10.

Comment 4

[Patrick (he/him)]

This bug appears to be a regression.

Having run mozregression on Windows 10, the last good build is 2019-08-13, and the first broken build is 2019-08-14.

From mozregression:

2019-12-31T14:31:18: DEBUG : Found commit message:
Bug 1563587, Make history.back/forward/go asynchronous, r=farre

The main part of the change is the change to ChildSHistory - make it possible to have Go() to be called asynchronously
and also let one to cancel pending history navigations. History object (window.history) can then use either the sync or
async Go(), depending on the dom.window.history.async pref.

LoadDelegate, which is used by GeckoView, needs special handling, since
it spins event loop nestedly. With session history loads and same-document loads we can just
bypass it.
To deal with same-document case, MaybeHandleSameDocumentNavigation is split to IsSameDocumentNavigation,
which collects relevant information about the request and returns true if same-document navigation should happen,
and then later HandleSameDocumentNavigation uses that information to trigger the navigation.
SameDocumentNavigationState is used to pass the information around.

referrer-policy-test-case.sub.js is buggy causing tests to pass only on Firefox with sync history API.

nested-context-navigations-iframe.html.ini is added because of https://bugzilla.mozilla.org/show_bug.cgi?id=1572932

Differential Revision: https://phabricator.services.mozilla.com/D41199

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

Not sure if this is an evangelism bug or something else.

Comment 6

[Patrick (he/him)]

This issue is no longer reproducible in Nightly 74.0a1 (2020-01-11). According to mozregression, the fix was bug 1606157

Narrowed inbound regression window from [f0890a32, 32d6e8a3] (4 builds) to [9008ec7a, 32d6e8a3] (2 builds) (~1 steps left)
2020-01-12T14:02:29: DEBUG : Starting merge handling...
2020-01-12T14:02:29: DEBUG : Using url: https://hg.mozilla.org/integration/autoland/json-pushes?changeset=32d6e8a34f39f8f00e2eae7fd1b01186f80e182c&full=1
2020-01-12T14:02:30: DEBUG : Found commit message:
Bug 1606157 - ServiceWorkerJob notify callbacks its being discarded r=asuth

Differential Revision: https://phabricator.services.mozilla.com/D59007

Comment 7

[Patrick (he/him)]

Hi Stansult
Are you still able to reproduce this issue in Firefox on Mac OS X?

Comment 8

[stansult]

(In reply to mpj.5 from comment #7)

Hi Stansult
Are you still able to reproduce this issue in Firefox on Mac OS X?

Yes. Just tried, still reproduces.
Firefox 72.0.1 (64-bit),
macOS Catalina, 10.15.2

Comment 9

[Ryan VanderMeulen [:RyanVM]]

To be clear, the only release expected to be fixed at this point in time are Nightly builds for what will eventually be Firefox 74, though there's also some discussion about possibly backporting the fix to Beta for Firefox 73 as well. Firefox 72 hasn't received this fix nor will it.

Comment 10

[Perry Jiang [:perry] [no longer employee, use ni?]]

Hi mpj.5, what's the value of the preference "dom.serviceWorkers.parent_intercept" for you that you used for mozregression/reproducing? I would like to nominate bug 1606157 for backporting but it's not immediately obvious how bug 1606157's fix would fix this too. I didn't imagine it would affect anything except browser shutdown.

Comment 11

[Patrick (he/him)]

Hi Perry,
I'll need to dig deeper. I tried to redo mozregression, but found the issue was occuring even in builds that I thought were 'fixed'.

I subsequently discovered that the issue is still reproducible in Nightly if I create a new profile.

It looks like I may have mislead you all - terribly sorry!

Comment 12

[Patrick (he/him)]

Further testing has revealed that this is still reproducible in 74.0a1 (2020-01-13), in a fresh profile.

Comment 13

[Patrick (he/him)]

Attachment: prefs.js from Working Profile

This prefs.js file is from a profile where the issue cannot be reproduced - I've been unable to pinpoint which preference has made the difference.

Comment 14

[Patrick (he/him)]

Hi Stansult
I just tried to do some more testing, and found I could no longer reproduce this bug, including in the build I originally confirmed it in. So I'm thinking there might have been a fix on Google's end. Can you still reproduce it?

Comment 15

[stansult]

(In reply to mpj.5 from comment #14)

Hi Stansult
I just tried to do some more testing, and found I could no longer reproduce this bug, including in the build I originally confirmed it in. So I'm thinking there might have been a fix on Google's end. Can you still reproduce it?

Yup. Retested in the same build (72.0.1), can’t repro anymore.
Looks like it’s fixed.

Comment 16

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

The severity field for this bug is relatively low, S3. However, the bug has 10 votes.
:smaug, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 17

[Andrew McCreight [:mccr8]]

Marking WORKSFORME per the last few non-bot comments.