Closed
Bug 1395187
Opened 7 years ago
Closed 6 years ago
It seems that it takes a long time to start the browser since Bug 1384336 landed
Categories
(Core :: DOM: Content Processes, defect, P1)
Tracking
()
VERIFIED
FIXED
mozilla59
Tracking | Status | |
---|---|---|
firefox-esr52 | --- | unaffected |
firefox55 | --- | unaffected |
firefox56 | --- | unaffected |
firefox57 | --- | wontfix |
firefox58 | --- | verified |
firefox59 | --- | verified |
People
(Reporter: alice0775, Assigned: bobowen)
References
(Blocks 1 open bug)
Details
(Keywords: regression)
Attachments
(5 files)
13.96 KB,
text/plain
|
Details | |
1.68 MB,
video/x-ms-wmv
|
Details | |
1.31 MB,
video/x-ms-wmv
|
Details | |
4.00 KB,
patch
|
jimm
:
review+
lizzard
:
approval-mozilla-beta+
|
Details | Diff | Splinter Review |
1.52 KB,
patch
|
Details | Diff | Splinter Review |
Reproducible: always Steps To reproduce: 1. Launch Nightly Actual Results: After browser window display, mouse cursor turn to "progress"(Arrow+hourglass) shape. And it takes about 5 sec to turn to "default"(Arrow) shape. Expected Results: It should be less than 2 seconds to turn to "default"(Arrow) shape. Regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=24d5dbf3a9dcadf708aa6874d9cfbe911af3d3d7&tochange=01fd73e4b8b89080505bf9f004c82c3e1043f40e Regressed by: Bug 1384336
Reporter | ||
Comment 1•7 years ago
|
||
Reporter | ||
Comment 2•7 years ago
|
||
Reporter | ||
Comment 3•7 years ago
|
||
Flags: needinfo?(wmccloskey)
Is this bug only about the cursor, or does the window take longer to finish painting as well?
Reporter | ||
Comment 5•7 years ago
|
||
It seems cursor only.
Comment 6•7 years ago
|
||
Let me add what I am seeing. A new profile and safe-mode displays the arrow/busy pointer for about 6 or 7 seconds before it turns to a regular pointer. If I have a home page open up when I start Fx the pointer behaves as mentioned above. However, if I open up to a blank page I get just the busy pointer which will last forever unless I do something else with the busy pointer like moving it over a toolbar. At this point it changes back to a normal pointer. Since this only happens on my production profile, with add-ons, this might be an add-on issue. Also, when I open up my first new tab after I start Fx I get the same arrow/busy pointer. After this, opening up a new empty tab behaves normally, no arrow/busy pointer until I exit and start Fx again.
Comment 7•7 years ago
|
||
It appears the Webextension add-on AutoplayStopper is the culprit causing the busy pointer when Fx opens up to a blank page. With AS disabled it produces the arrow/busy pointer for 6-7 seconds. I'll let the developer of AS know these findings.
Comment 9•7 years ago
|
||
This should be fixed by a backout in bug 1397956.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Updated•7 years ago
|
Flags: needinfo?(wmccloskey)
Assignee | ||
Comment 10•6 years ago
|
||
Re-opening this, so it can be addressed and we can hopefully turn off native event processing in bug 1423628. (I think I already have a fix for this one.)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Updated•6 years ago
|
Assignee: wmccloskey → bobowencode
Status: REOPENED → ASSIGNED
Assignee | ||
Updated•6 years ago
|
Priority: -- → P1
Assignee | ||
Comment 11•6 years ago
|
||
Attachment #8935035 -
Flags: review?(jmathies)
Updated•6 years ago
|
Attachment #8935035 -
Flags: review?(jmathies) → review+
Assignee | ||
Comment 12•6 years ago
|
||
Thanks Jim. https://treeherder.mozilla.org/#/jobs?repo=try&revision=1f0d236c8a9a473184bef516edb62e1ff74f3870
Comment 13•6 years ago
|
||
Pushed by bobowencode@gmail.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/74c0d505722a Use STARTF_FORCEOFFFEEDBACK flag when starting Windows child processes to prevent app starting cursor. r=jimm
Comment 14•6 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/74c0d505722a
Status: ASSIGNED → RESOLVED
Closed: 7 years ago → 6 years ago
status-firefox59:
--- → fixed
Resolution: --- → FIXED
Target Milestone: mozilla57 → mozilla59
Assignee | ||
Comment 16•6 years ago
|
||
(In reply to Ryan VanderMeulen [:RyanVM] from comment #15) > What should the status of 57/58 be here? Sorry didn't spot that, this was triggered by turning off native event processing, but native event processing was re-enabled, because of this and other regressions. I'm working through the regressions, so we can try turning it off again.
Assignee | ||
Comment 17•6 years ago
|
||
Comment on attachment 8935035 [details] [diff] [review] Use STARTF_FORCEOFFFEEDBACK flag when starting Windows child processes to prevent app starting cursor Approval Request Comment [Feature/Bug causing the regression]: I realised that we have had the same problem with the GMP process since launch. [User impact if declined]: User currently gets 5-7 seconds background activity cursor every time we start a GMP process. Even though the video has already started. [Is this code covered by automated tests?]: The sandboxed process launch code is run in all e10s tests. [Has the fix been verified in Nightly?]: Yes. [Needs manual test from QE? If yes, steps to reproduce]: Yes. If you go to https://shaka-player-demo.appspot.com/demo/ you should see the background activity cursor for 5 to 7 seconds. (Assuming it doesn't get overridden for another reason, for example if you hover over a link.) [List of other uplifts needed for the feature/fix]: None. [Is the change risky?]: No. [Why is the change risky/not risky?]: Trivial one line change to add a standard flag to process start-up information. [String changes made/needed]: None.
Attachment #8935035 -
Flags: approval-mozilla-beta?
Assignee | ||
Updated•6 years ago
|
Comment 18•6 years ago
|
||
Comment on attachment 8935035 [details] [diff] [review] Use STARTF_FORCEOFFFEEDBACK flag when starting Windows child processes to prevent app starting cursor Fix a (child process) startup issue that started in 57 - let's uplift this for 58 beta 12.
Attachment #8935035 -
Flags: approval-mozilla-beta? → approval-mozilla-beta+
Updated•6 years ago
|
Comment 19•6 years ago
|
||
The patch cannot be uplifted to beta. grafting 454357:74c0d505722a "Bug 1395187: Use STARTF_FORCEOFFFEEDBACK flag when starting Windows child processes to prevent app starting cursor. r=jimm" other [graft] changed security/sandbox/chromium-shim/patches/after_update/patch_order.txt which local [local] deleted use (c)hanged version, leave (d)eleted, or leave (u)nresolved? Please take a look at this. Thanks!
Flags: needinfo?(bobowencode)
Assignee | ||
Comment 20•6 years ago
|
||
(In reply to Cosmin Sabou [:cosmin_sabou] from comment #19) ... > Please take a look at this. Thanks! Sorry about that, I didn't have a copy of beta at the all hands and I forgot about the fact I've changed the way we store the patches for the chromium sandbox. This is an uplift, so we don't need that part anyway. Here's a patch with just the actual code change.
Flags: needinfo?(bobowencode) → needinfo?(csabou)
Comment 21•6 years ago
|
||
bugherder uplift |
https://hg.mozilla.org/releases/mozilla-beta/rev/fd1e2b98664a
Updated•6 years ago
|
Flags: needinfo?(csabou)
Updated•6 years ago
|
Flags: qe-verify+
Comment 22•6 years ago
|
||
I have managed to reproduce this issue using the Nightly build 57.0a1 (20170830100230), on Windows 10 X64. I retested it using the latest Nightly 59.0a1 (20171219100203) and beta 58.0b12 (20171218174357), on the same platform and I can mark this issue as verified fixed.
Status: RESOLVED → VERIFIED
Flags: qe-verify+
Updated•6 years ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•