Closed
Bug 1427614
Opened 6 years ago
Closed 6 years ago
It takes about 8 seconds for navigation to start after click a link
Categories
(Core :: DOM: Core & HTML, defect, P2)
Tracking
()
RESOLVED
FIXED
mozilla59
Tracking | Status | |
---|---|---|
firefox-esr52 | --- | unaffected |
firefox57 | --- | unaffected |
firefox58 | --- | unaffected |
firefox59 | + | fixed |
People
(Reporter: alice0775, Assigned: farre)
References
Details
(Keywords: perf, regression, reproducible, Whiteboard: [parity-Chrome][parity-Edge])
Attachments
(1 file)
1.76 KB,
patch
|
bkelly
:
review+
|
Details | Diff | Splinter Review |
[Tracking Requested - why for this release]: Performance regression. UX degradation. It takes about 8 seconds(too long) for navigation to start (The tab loading icon starts animation). So, The user feels that mouse click failed.... Chrome and Edge works as expected. Reproducible: always Steps To Reproduce: 1. Open http://news.so-net.ne.jp/ in a foreground tab (I also experienced on several sites) 2. Wait for 3-4 minutes 3. Click one of link "社会" "経済" "国際" "エンタメ" "スポーツ" "話題" "ランキング" "写真" "動画" Actual Results: It takes about 8 seconds for navigation to start (The tab loading icon starts animation) Expected Results: It should start immediately. Repression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=0a667bf8c1a72692512122bedb41be805a4a19f1&tochange=baa75a4997524c032793ef508447ecc32bda622d Suspect:Bug 1372951 @:farre, Your patch seems to cause the performance regression. Could you look into this?
Flags: needinfo?(afarre)
Reporter | ||
Comment 1•6 years ago
|
||
Indeed, I can confirm that setting dom.min_tracking_timeout_value=4 fixes the problem.
Reporter | ||
Updated•6 years ago
|
Reporter | ||
Updated•6 years ago
|
Version: 56 Branch → Trunk
Assignee | ||
Comment 2•6 years ago
|
||
Note that dom.min_tracking_timeout_value is only set to enable foreground throttling on nightly. Still, it is as I feared a point against throttling on the foreground. I'll debug and verify that I'm correct and that there's nothing to do about it. Maybe throttling could be disabled if we can determine that user interaction is the source, but I'm not sure of if even that would be enough.
Flags: needinfo?(afarre)
Assignee | ||
Updated•6 years ago
|
Assignee: nobody → afarre
Updated•6 years ago
|
Priority: -- → P2
Comment 3•6 years ago
|
||
Does that mean the issue will stay in nightly? Or is it going to move to beta for 59?
Flags: needinfo?(afarre)
Assignee | ||
Comment 4•6 years ago
|
||
The issue will not move to beta, and I'm going to fix it for nightly.
Flags: needinfo?(afarre)
Assignee | ||
Comment 5•6 years ago
|
||
Turn off throttling even though it's only turned on for Nightly.
Attachment #8943624 -
Flags: review?(bkelly)
Updated•6 years ago
|
Attachment #8943624 -
Flags: review?(bkelly) → review+
Assignee | ||
Updated•6 years ago
|
Keywords: checkin-needed
Pushed by ryanvm@gmail.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/b20af51cfab3 Turn off foreground throttling of tp timeouts. r=bkelly
Keywords: checkin-needed
Comment 7•6 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/b20af51cfab3
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla59
Updated•5 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•