Closed Bug 1106936 Opened 11 years ago Closed 11 years ago

[e10s] Loading Spinner Doesn't Activate

Categories

(Firefox :: Tabbed Browser, defect)

defect
Not set
normal
Points:
3

Tracking

()

VERIFIED FIXED
Firefox 37
Iteration:
37.1
Tracking Status
e10s ? ---
firefox37 --- verified

People

(Reporter: tech4pwd, Assigned: ttaubert)

References

Details

(Keywords: regression)

Attachments

(1 file)

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:37.0) Gecko/20100101 Firefox/37.0 Build ID: 20141202213802 Steps to reproduce: The loading spinner doesn't activate (that's the one that spins to the right), only the connecting spinner activates. Actual results: The problem is that this gives the perception of much slower load time than what actually happens. The user is made to feel like the machine is struggling to connect. Expected results: The loading/rendering spinner should appear as per non-e10s.
Blocks: 1100340
I can seethe problem on latest Nightly e10s windows7.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
tracking-e10s: --- → ?
Regression window(fx) Good: https://hg.mozilla.org/integration/fx-team/rev/7553b7c1f35f Mozilla/5.0 (Windows NT 6.1; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0 ID:20141117141551 Bad: https://hg.mozilla.org/integration/fx-team/rev/ad799d59abdc Mozilla/5.0 (Windows NT 6.1; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0 ID:20141117143554 Pushlog: https://hg.mozilla.org/integration/fx-team/pushloghtml?fromchange=7553b7c1f35f&tochange=ad799d59abdc Regressed by; ad799d59abdc Tim Taubert — Bug 1099490 - [e10s] Use nsBrowserStatusFilter in the content to avoid a flood of progress messages being sent to the parent r=billm
Blocks: 1099490
No longer blocks: 1100340
Component: Untriaged → Tabbed Browser
Flags: needinfo?(ttaubert)
Keywords: regression
Flags: qe-verify+
Flags: needinfo?(ttaubert)
Flags: firefox-backlog+
Hardware: x86 → All
I initially thought this was caused by the double-filtering in e10s but it actually is caused by the RemoteWebProgress not sending onProgressChange() notifications.
Assignee: nobody → ttaubert
Status: NEW → ASSIGNED
Attachment #8531719 - Flags: review?(wmccloskey)
Iteration: --- → 37.1
Points: --- → 3
Attachment #8531719 - Flags: review?(wmccloskey) → review+
Backed out for m1-e10s failures: https://hg.mozilla.org/integration/fx-team/rev/faee1a0dc304 TEST-UNEXPECTED-FAIL | /tests/docshell/test/test_bug475636.html | Test timed out. - expected PASS
onRefreshAttempted() should of course default to allowing the action as long as we haven't implemented it yet. https://tbpl.mozilla.org/?tree=Try&rev=5f974f323d14
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 37
I was able to reproduce this issue on Firefox 37.0a1 (2014-12-02) using Windows 7 x64. Verified fixed on Latest Firefox 37.0a1 (2014-12-10) using Windows 7 x64, Ubuntu 12.04 x86 and Mac OSX 10.9.5.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: