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

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: Screencasting, defect)

Description

[James Willcox (:snorp) ([e-mail]) (he/him)]

Play Store reviews are saying they can't load pages. Only see a white screen.

Comment 1

[James Willcox (:snorp) ([e-mail]) (he/him)]

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.

Comment 2

[James Willcox (:snorp) ([e-mail]) (he/him)]

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.

Comment 3

[James Willcox (:snorp) ([e-mail]) (he/him)]

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?

Comment 4

[James Willcox (:snorp) ([e-mail]) (he/him)]

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....

Comment 5

[James Willcox (:snorp) ([e-mail]) (he/him)]

Attachment: 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.

Comment 6

[James Willcox (:snorp) ([e-mail]) (he/him)]

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....

Comment 7

[James Willcox (:snorp) ([e-mail]) (he/him)]

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?

Comment 8

[Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz)]

It was used to lookup Firefox OS devices for video casting. We can uplift bug 1322602 to Fennec 52.

Comment 10

[Sebastian Kaspari (:sebastian; :pocmo)]

Copying the flags from bug 1340465: I can only reproduce it in 52 (and already happened in 52 Beta).

Comment 12

[Paul M]

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.

Comment 13

[James Willcox (:snorp) ([e-mail]) (he/him)]

Shih-Chiang, I requested uplift on bug 1322602, but do you have any objections to simply flipping the network.mdns.use_js_fallback pref?

Comment 14

[James Willcox (:snorp) ([e-mail]) (he/him)]

Attachment: Bug 1347755 - Disable JS MDNS fallback and presentation API on Android

Review commit: https://reviewboard.mozilla.org/r/121044/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/121044/

Comment 15

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Tracking as a blocker. Let's try to get a fix for this in place and roll up into the first dot release.

Comment 16

[(inactive) Jim Chen [:jchen] [:darchons]]

Comment on attachment 8848086 [details]
Bug 1347755 - Disable JS MDNS fallback and presentation API on Android

https://reviewboard.mozilla.org/r/121044/#review123088

Comment 17

[James Willcox (:snorp) ([e-mail]) (he/him)]

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

Comment 18

[James Willcox (:snorp) ([e-mail]) (he/him)]

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.

Comment 19

[James Willcox (:snorp) ([e-mail]) (he/him)]

Comment on attachment 8848086 [details]
Bug 1347755 - Disable JS MDNS fallback and presentation API on Android

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/121044/diff/1-2/

Comment 20

[Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz)]

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.

Comment 21

[Bogdan Surd, QA [:bsurd, NI]]

Changing component to Screencasting, if anyone thinks this is not the right component please feel free to change it back.

Comment 22

[James Willcox (:snorp) ([e-mail]) (he/him)]

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

Comment 24

[Julien Cristau [:jcristau]]

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.

Comment 25

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-release/rev/284d893e00bd

Comment 26

[Ryan VanderMeulen [:RyanVM]]

Should be in tomorrow's CI builds if QA wants to get a jump start on testing this.

Comment 27

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Hi Ioana, Florin, can you please add this scenario to Fennec sign offs? Is this scenario already included in your list of key scenarios?

Comment 28

[Ioana Chiorean]

We can add this to the signoff, yes. Will look at this today.

Comment 29

[u549602]

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.

Comment 30

[u549602]

Still reproducible after the fix

Comment 31

[u549602]

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)

Comment 32

[James Willcox (:snorp) ([e-mail]) (he/him)]

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).

Comment 33

[u549602]

 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.

Comment 34

[u549602]

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.

Comment 35

[James Willcox (:snorp) ([e-mail]) (he/him)]

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).

Comment 36

[e_post_adresse]

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.