Can't load pages in Firefox 52 with a Chromecast device on the same network

RESOLVED FIXED in Firefox 52

Status

()

Firefox for Android
Screencasting
RESOLVED FIXED
a year ago
6 hours ago

People

(Reporter: snorp, Assigned: snorp)

Tracking

52 Branch
Firefox 52
Points:
---

Firefox Tracking Flags

(firefox52blocking fixed, firefox53 unaffected, firefox54 unaffected, firefox55 unaffected)

Details

MozReview Requests

()

Submitter Diff Changes Open Issues Last Updated
Loading...
Error loading review requests:

Attachments

(2 attachments)

Play Store reviews are saying they can't load pages. Only see a white screen.
status-firefox52: --- → affected
tracking-firefox52: --- → ?
I can reproduce some extremely sluggish behavior now with 52 on my Pixel. It seems like the Gecko thread gets hung up on something. Investigating further....

Jim, it would be helpful if you can try to repro/debug this as well.
Flags: needinfo?(nchen)
The symptoms for me are very slow page load times, followed by inability to "fling". Additionally, when panning, I see low-res tiles for a long period of time (many seconds). 'top' shows 25% CPU usage while we are in this hung state, which I believe means one core of this quad-core device is totally pegged.
I was able to connect with devtools and it looks like we're doing a bunch of stuff in MulticastDNS.jsm. I have a Chromecast and several Apple devices on the network, maybe something is going wrong there?
I can't reproduce the issue with wifi turned off, so I think I'm on the right track here. I am not aware of any changes around here in 52, however....
Created attachment 8847871 [details]
Profile taken while reproducing hosed browser

I managed to get a profile via devtools while the browser was hung. I'll see if I can get a better one with the profiler addon.
OK, setting 'network.mdns.use_js_fallback' to false seems to make things better for me. I think we need to push a hotfix (or respin?) with that pref flipped. I don't know if it breaks Chromecast or flyweb or whatever, but I don't much care right now....
It looks like bug 1129785 introduced the use of the JS mDNS code, but that's been in since 47. I'm not sure what caused the recent change.

Shih-Chiang, do you remember why you needed the JS mDNS for the presentation API?
Depends on: 1129785
Flags: needinfo?(schien)
It was used to lookup Firefox OS devices for video casting. We can uplift bug 1322602 to Fennec 52.
Flags: needinfo?(schien)
Duplicate of this bug: 1340465
See Also: → bug 1347054
Summary: Can't load pages in Firefox 52 → Can't load pages in Firefox 52 while doing a video casting with a Chromecast device
Copying the flags from bug 1340465: I can only reproduce it in 52 (and already happened in 52 Beta).
status-firefox53: --- → unaffected
status-firefox54: --- → unaffected
status-firefox55: --- → unaffected
Duplicate of this bug: 1347054

Comment 12

a year ago
I suggest the title is better revised to "Can't load pages in Firefox 52 with Chromecast device on network".

See Bug 1347054, Comment 10.
status-firefox53: unaffected → ---
status-firefox54: unaffected → ---
status-firefox55: unaffected → ---
status-firefox53: --- → unaffected
status-firefox54: --- → unaffected
status-firefox55: --- → unaffected
Shih-Chiang, I requested uplift on bug 1322602, but do you have any objections to simply flipping the network.mdns.use_js_fallback pref?
Flags: needinfo?(schien)
Summary: Can't load pages in Firefox 52 while doing a video casting with a Chromecast device → Can't load pages in Firefox 52 with a Chromecast device on the same network
Comment hidden (mozreview-request)
Tracking as a blocker. Let's try to get a fix for this in place and roll up into the first dot release.
tracking-firefox52: ? → blocking
See Also: bug 1347054

Comment 16

a year ago
mozreview-review
Comment on attachment 8848086 [details]
Bug 1347755 - Disable JS MDNS fallback and presentation API on Android

https://reviewboard.mozilla.org/r/121044/#review123088
Attachment #8848086 - Flags: review?(nchen) → review+
Comment on attachment 8848086 [details]
Bug 1347755 - Disable JS MDNS fallback and presentation API on Android

Approval Request Comment
[Feature/Bug causing the regression]: Unknown
[User impact if declined]: Hangs and general slowness in 52
[Is this code covered by automated tests?]: No
[Has the fix been verified in Nightly?]: Not specifically this patch, but a similar patch already exists in 53+
[Needs manual test from QE? If yes, steps to reproduce]: Yes.

1) Have a Chromeast on the same wifi network as phone
2) Verify that with the patch, Firefox can load pages quickly

[List of other uplifts needed for the feature/fix]: None
[Is the change risky?]: No
[Why is the change risky/not risky?]: Flips a pref that only affects mDNS services, a non-critical system
[String changes made/needed]: None
Attachment #8848086 - Flags: approval-mozilla-release?
Ugh, hold on. I think we actually want to go ahead and disable presentation API as well, since that's what uses the mDNS bits. There was a problem at one point where the Java mDNS service was killing people's batteries.
Attachment #8848086 - Attachment is obsolete: true
Attachment #8848086 - Flags: approval-mozilla-release?
Comment hidden (mozreview-request)
Yeah the mdns.jsm is introduced because of the power consumption issue (see bug 1215012). If you want to solely disable the mdns discovery triggered by presentation API the try disable "dom.presentation.discovery.enabled" and "dom.presentation.discovery.legacy.enabled" in https://hg.mozilla.org/releases/mozilla-release/file/tip/mobile/android/app/mobile.js#l910.
Flags: needinfo?(schien)
Changing component to Screencasting, if anyone thinks this is not the right component please feel free to change it back.
Component: General → Screencasting
Comment on attachment 8848086 [details]
Bug 1347755 - Disable JS MDNS fallback and presentation API on Android

Approval Request Comment
[Feature/Bug causing the regression]: Unknown
[User impact if declined]: Hangs and general slowness in 52
[Is this code covered by automated tests?]: No
[Has the fix been verified in Nightly?]: Not specifically this patch, but a similar patch already exists in 53+
[Needs manual test from QE? If yes, steps to reproduce]: Yes.

1) Have a Chromeast on the same wifi network as phone
2) Verify that with the patch, Firefox can load pages quickly

[List of other uplifts needed for the feature/fix]: None
[Is the change risky?]: No
[Why is the change risky/not risky?]: Flips a pref that only affects mDNS services, a non-critical system
[String changes made/needed]: None
Attachment #8848086 - Flags: approval-mozilla-release?
Flags: needinfo?(nchen)

Updated

a year ago
Duplicate of this bug: 1348778
Comment on attachment 8848086 [details]
Bug 1347755 - Disable JS MDNS fallback and presentation API on Android

let's disable this for 52.0.2

Ioana, it would be great if you could verify the fix when it hits release.
Flags: needinfo?(ioana.chiorean)
Attachment #8848086 - Flags: approval-mozilla-release? → approval-mozilla-release+

Comment 25

a year ago
bugherderuplift
https://hg.mozilla.org/releases/mozilla-release/rev/284d893e00bd
status-firefox52: affected → fixed
Should be in tomorrow's CI builds if QA wants to get a jump start on testing this.
Assignee: nobody → snorp
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 52
Hi Ioana, Florin, can you please add this scenario to Fennec sign offs? Is this scenario already included in your list of key scenarios?
Flags: needinfo?(florin.mezei)

Comment 28

a year ago
We can add this to the signoff, yes. Will look at this today.
Flags: needinfo?(florin.mezei)
Hi,

Tried verifying this on a Samsung Galaxy S6 EDGE (Android 6.0) while playing youtube videos using a Nexus Player.
The build on which this was verified was the 1490040924 tinder build and indeed, the "dom.presentation.discovery.enabled" and "dom.presentation.discovery.legacy.enabled" params are disabled by default but no major differences could be noticed when loading pages on mobile. 
In conclusion, no major difference between the release build and the one that the fix was uplifted to.
Still reproducible after the fix
Flags: needinfo?(snorp)

Updated

a year ago
Flags: needinfo?(ioana.chiorean)
After further testing seems that the issue is reproducible also on : 49 release, 51 release and 53.0b5. There is this stall (3-4 seconds) at some point when loading a page and afterwards the page loads ok (this on all builds with chromecast)
Mihai, this manifests as a hang much longer than 3s for me. The browser is unusable for at least 30s in most cases. Did you see this behavior before the change? I'm out of town so don't have access to the environment I was using before. A 3s hang may be some other unrelated issue (like just starting up gecko).
Flags: needinfo?(snorp)
Flags: needinfo?(mihai.ninu)
 No such times were reached on my side, even on the builds prior the fix uplift 52.0b11 and 52.0.1, could not reproduce those hang times. 
So, in that case seems that the issue could not be reproduced to start from by me.
Flags: needinfo?(mihai.ninu)
Hi,
Tried reproducing this on 52.0.2 today on our sign-off test run and failed miserably. This time the devices used were Nexus 9 (Android N) and Samsung Galaxy S6 Edge (Android 6.0).
James, if you reproduced this, can you please try to verify this?
Thanks a lot.
Flags: needinfo?(snorp)
I can no longer reproduce it with 52.0. I guess something changed in my environment.

I don't think the patch can make it worse, and we have strong evidence to suggest that it fixes the issue (since it did when I was able to reproduce it).
Flags: needinfo?(snorp)

Comment 36

a year ago
I can confirm that I have what seems to be this issue on my Nexus 6 with 52.0.1. Both disabling wifi and setting 'network.mdns.use_js_fallback' to false seemed to work for me.

Updated

10 months ago
See Also: → bug 1374647

Updated

6 hours ago
See Also: → bug 1455618
You need to log in before you can comment on or make changes to this bug.