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)

57 Branch
x86_64
Windows 10
defect

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)

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
Attached file about:support
Flags: needinfo?(wmccloskey)
Is this bug only about the cursor, or does the window take longer to finish painting as well?
It seems cursor only.
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.
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.
Depends on: 1397956
This should be fixed by a backout in bug 1397956.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Assignee: nobody → wmccloskey
Target Milestone: --- → mozilla57
Flags: needinfo?(wmccloskey)
Blocks: 1423628
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: wmccloskey → bobowencode
Status: REOPENED → ASSIGNED
Priority: -- → P1
Attachment #8935035 - Flags: review?(jmathies) → review+
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
https://hg.mozilla.org/mozilla-central/rev/74c0d505722a
Status: ASSIGNED → RESOLVED
Closed: 7 years ago6 years ago
Resolution: --- → FIXED
Target Milestone: mozilla57 → mozilla59
What should the status of 57/58 be here?
Flags: needinfo?(bobowencode)
(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.
Flags: needinfo?(bobowencode)
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?
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+
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)
(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)
Flags: needinfo?(csabou)
Flags: qe-verify+
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+
Blocks: 1399891
You need to log in before you can comment on or make changes to this bug.