Closed Bug 1348623 Opened 3 years ago Closed 3 years ago

Regression: events on chrome aren't being triggered while the page changes

Categories

(Core :: DOM: Events, defect)

53 Branch
x86
Windows 10
defect
Not set

Tracking

()

VERIFIED FIXED
mozilla55
Tracking Status
firefox52 --- unaffected
firefox-esr52 --- unaffected
firefox53 + verified
firefox54 + verified
firefox55 + verified

People

(Reporter: tustamido, Assigned: Gijs)

References

Details

(Keywords: regression)

Attachments

(2 files)

Steps to reproduce:

1. In Firefox 53+, disable e10s;

2. Run the following test code in Browser Console or Scratchpad:
window.addEventListener('mousedown', function(e){if (e.button === 1) console.log('Middleclicked!')}, true);

3. Open a new tab and paste the URL of a fairly heavy page (I tested with globoesporte.globo.com);

4. After pressing Enter to load the page, quickly middleclick anywhere in the blank content (since the page has not yet started to be displayed).


Actual results:

The event is not triggered, as you can (not) see in the console log.


Expected results:

"Middleclick" should be in console, as happened until Firefox 52.


This bug is disturbing my mouse gestures/rocker gestures script.


mozregression:

pushlog_url: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=f707a43789429c4bae74eb50ead0272d7b36da95&tochange=d643dc8256bf96e54aae56943d8e62f45f36f053

Using url: https://hg.mozilla.org/integration/autoland/json-pushes?changeset=512d5944a602d037a7c3455190a41f39aab37c9a&full=1

DEBUG : Found commit message:

Bug 1044586 - fix propagating document events to the window when the inner window has changed, r=smaug

MozReview-Commit-ID: G6yPBwbITvG
Gijs, could you check this regression when you have some time, please.
Blocks: 1044586
Status: UNCONFIRMED → NEW
Has Regression Range: --- → yes
Has STR: --- → yes
Ever confirmed: true
Flags: needinfo?(gijskruitbosch+bugs)
Keywords: regression
OS: Unspecified → Windows 10
Hardware: Unspecified → x86
Olli, based on the patch in bug 1044586 and the STR, it seems that in these cases the clicks (from actual mouse interaction) fire on a document whose inner window is not the current inner window. How is that possible? :-\
Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(bugs)
The short time when new page hasn't been painted yet
Flags: needinfo?(bugs)
Tracking 53/54/55+ to investigate this - sounds important to clarify what is going on.
Comment on attachment 8849188 [details]
Bug 1348623 - revert changes from bug 1044586 and fix preferences reload bug by changing the event listener,

https://reviewboard.mozilla.org/r/122024/#review124036
Attachment #8849188 - Flags: review?(bugs) → review+
Assignee: nobody → gijskruitbosch+bugs
Status: NEW → ASSIGNED
Pushed by gijskruitbosch@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/9ad182a89831
revert changes from bug 1044586 and fix preferences reload bug by changing the event listener, r=smaug
Comment on attachment 8849188 [details]
Bug 1348623 - revert changes from bug 1044586 and fix preferences reload bug by changing the event listener,

Approval Request Comment
[Feature/Bug causing the regression]: bug 1044586
[User impact if declined]:  web & user-observable side-effects that make events go missing
[Is this code covered by automated tests?]: no, because this is almost impossible to test automatically in a reliable fashion
[Has the fix been verified in Nightly?]: not yet
[Needs manual test from QE? If yes, steps to reproduce]: re-verifying bug 1044586 would be prudent. For this:
1. open firefox
2. open the options/preferences
3. press and hold F5 or cmd-r (on OS X) for 2-3 seconds

Expected: prefs load correctly
With just a backout of bug 1044586: the preferences get 'stuck' showing the search pane with no content, with JS errors in the console

[List of other uplifts needed for the feature/fix]: n/a
[Is the change risky?]: no
[Why is the change risky/not risky?]: it's a straight backout plus an alternative fix for the already well-understood issue from bug 1044586. The fix will only affect about:preferences, and so this will bring 53/54 back in line with 52 as far as event propagation to DOM windows goes.
[String changes made/needed]: none
Attachment #8849188 - Flags: approval-mozilla-beta?
Attachment #8849188 - Flags: approval-mozilla-aurora?
Merged to m-c in https://hg.mozilla.org/mozilla-central/rev/9ad182a89831
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
Hi Brindusa, could you help find someone to verify if this issue was fixed as expected on a latest Nightly build? Thanks!
Flags: needinfo?(brindusa.tot)
Comment on attachment 8849188 [details]
Bug 1348623 - revert changes from bug 1044586 and fix preferences reload bug by changing the event listener,

Fix a missing event regression. Aurora54+ & Beta53+.
Attachment #8849188 - Flags: approval-mozilla-beta?
Attachment #8849188 - Flags: approval-mozilla-beta+
Attachment #8849188 - Flags: approval-mozilla-aurora?
Attachment #8849188 - Flags: approval-mozilla-aurora+
Flags: qe-verify+
Attached video Screencast1.mp4
Reproduced the scenario from Comment 9 on Nightly 53.0a1 (Build ID: 20161125030214).

And I can confirm that the scenario from Comment 9 is no longer reproducible on Windows 10 x64 and Ubuntu 16.04 x64. 
But on Mac OS X 10.12, even though I'm not seeing the search pane with no content, I'm getting the following Security Error:
"ReferenceError: gSyncPane is not defined[Learn More] preferences.js:66:3
Gijs, is this expected?

Also, I could not reproduce the initial issue as described by the reporter(I'm getting the same results on the affected Nightly 53.0a1 as I do on the latest Nightly 55.0a1). Am I missing something here? (please see the screencast?)
Flags: needinfo?(brindusa.tot) → needinfo?(gijskruitbosch+bugs)
(In reply to Simona B [:simonab ] from comment #15)
> Created attachment 8850937 [details]
> Screencast1.mp4
> 
> Reproduced the scenario from Comment 9 on Nightly 53.0a1 (Build ID:
> 20161125030214).
> 
> And I can confirm that the scenario from Comment 9 is no longer reproducible
> on Windows 10 x64 and Ubuntu 16.04 x64. 
> But on Mac OS X 10.12, even though I'm not seeing the search pane with no
> content, I'm getting the following Security Error:
> "ReferenceError: gSyncPane is not defined[Learn More] preferences.js:66:3
> Gijs, is this expected?

That's hard to say without more information. Does the preferences UI work after you stop refreshing? Do you see the same error on Nightly 55 builds prior to this change landing?

> Also, I could not reproduce the initial issue as described by the
> reporter(I'm getting the same results on the affected Nightly 53.0a1

I think you'd have to use current an early beta of 53, or a Nightly from before this fix landed and after bug 1044586 landed, so later than 20161125030214 , to reproduce.
Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(simona.marcu)
(In reply to :Gijs from comment #16)
> > And I can confirm that the scenario from Comment 9 is no longer reproducible
> > on Windows 10 x64 and Ubuntu 16.04 x64. 
> > But on Mac OS X 10.12, even though I'm not seeing the search pane with no
> > content, I'm getting the following Security Error:
> > "ReferenceError: gSyncPane is not defined[Learn More] preferences.js:66:3
> > Gijs, is this expected?
> 
> That's hard to say without more information. Does the preferences UI work
> after you stop refreshing? 

Yes, it works.

>Do you see the same error on Nightly 55 builds prior to this change landing?

On a Nightly 55 prior the change (Build ID: 20170320030209) -  I'm also seeing the Security error "ReferenceError: gSyncPane is not defined[Learn More]  preferences.js:69:3"

> 
> > Also, I could not reproduce the initial issue as described by the
> > reporter(I'm getting the same results on the affected Nightly 53.0a1
> 
> I think you'd have to use current an early beta of 53, or a Nightly from
> before this fix landed and after bug 1044586 landed, so later than
> 20161125030214 , to reproduce.

I also tested on Firefox 53.0b2 and Firefox 53.0b6 (Build ID: 20170323090023) and I'm still getting the same results.
Flags: needinfo?(simona.marcu) → needinfo?(gijskruitbosch+bugs)
(In reply to Simona B [:simonab ] from comment #17)
> (In reply to :Gijs from comment #16)
> > > And I can confirm that the scenario from Comment 9 is no longer reproducible
> > > on Windows 10 x64 and Ubuntu 16.04 x64. 
> > > But on Mac OS X 10.12, even though I'm not seeing the search pane with no
> > > content, I'm getting the following Security Error:
> > > "ReferenceError: gSyncPane is not defined[Learn More] preferences.js:66:3
> > > Gijs, is this expected?
> > 
> > That's hard to say without more information. Does the preferences UI work
> > after you stop refreshing? 
> 
> Yes, it works.
> 
> >Do you see the same error on Nightly 55 builds prior to this change landing?
> 
> On a Nightly 55 prior the change (Build ID: 20170320030209) -  I'm also
> seeing the Security error "ReferenceError: gSyncPane is not defined[Learn
> More]  preferences.js:69:3"

OK, so then I'm not worried about this.

> > > Also, I could not reproduce the initial issue as described by the
> > > reporter(I'm getting the same results on the affected Nightly 53.0a1
> > 
> > I think you'd have to use current an early beta of 53, or a Nightly from
> > before this fix landed and after bug 1044586 landed, so later than
> > 20161125030214 , to reproduce.
> 
> I also tested on Firefox 53.0b2 and Firefox 53.0b6 (Build ID:
> 20170323090023) and I'm still getting the same results.

OK. Reporter, can you try a nightly build and check if you can check if this is fixed? I'm also struggling to reproduce the original problem on 53, so I can't confirm whether anything is fixed. :-\
Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(tustamido)
The fix was uplifted, that's why I can't reproduce on the latest Beta (53.0b6, 20170323090023).

I'm able to reproduce the original problem on 53.0b5 (20170320143328), for example.

It's fixed in all current channels, since it never affected 52.

But...

If you replace the second step to reproduce by:

2. Open a new tab, open an about: page (except about:newpage; tried with about:blank and about:buildconfig), then paste the URL of a fairly heavy page (I tested with globoesporte.globo.com);

This way I can reproduce the bug in almost all versions! Tried with 55, 54, 53, 52, 50, 48, 45, 40, 35, 30 and 25, all affected. Remembering to disable e10s.

I used about:blank as my new tab URL and had to change to default (about:newtab) to avoid this failure. Should I open a new bug?
Flags: needinfo?(tustamido)
replace the THIRD* step, sorry (can't edit my comment?)
(In reply to tustamido from comment #19)
> The fix was uplifted, that's why I can't reproduce on the latest Beta
> (53.0b6, 20170323090023).
> 
> I'm able to reproduce the original problem on 53.0b5 (20170320143328), for
> example.
> 
> It's fixed in all current channels, since it never affected 52.
> 
> But...
> 
> If you replace the [third] step to reproduce by:
> 
> 3. Open a new tab, open an about: page (except about:newpage; tried with
> about:blank and about:buildconfig), then paste the URL of a fairly heavy
> page (I tested with globoesporte.globo.com);
> 
> This way I can reproduce the bug in almost all versions! Tried with 55, 54,
> 53, 52, 50, 48, 45, 40, 35, 30 and 25, all affected. Remembering to disable
> e10s.
> 
> I used about:blank as my new tab URL and had to change to default
> (about:newtab) to avoid this failure. Should I open a new bug?

Yes please. I don't see why about:newtab would be any different from the others, and neither me nor Simona could reproduce the original issue... it's likely that it depends in some way or other on the speed of the internet connection or the machine. Have you doublechecked you can reproduce with a clean profile (no add-ons or custom prefs beyond disabling e10s) ?

Either way, sounds like this is verified as fixed as reported in that the regression is now gone, so marking this verified.
Yes, of course. I used mozregression, always creating new and clean profiles.

Based on screencast, Simona middleclicked too fast, before the page effectively began to load, before receive response headers or something like this (I don't know network process details). This way my middleclick is registered too.

I can reproduce the issue waiting something like 0.5s ~ 1.0s from Enter. After the page title is displayed, but before the content is painted. That's why I suggested using a heavy page.

Seems that Loic also managed to reproduce it.
Depends on: 1351674
You need to log in before you can comment on or make changes to this bug.