Closed Bug 1396440 Opened 7 years ago Closed 7 years ago

e10s breaks middlemouse.contentLoadURL on internal error pages

Categories

(Firefox :: General, defect)

55 Branch
defect
Not set
normal

Tracking

()

VERIFIED FIXED
Firefox 57
Tracking Status
firefox57 --- verified

People

(Reporter: mozilla, Assigned: mozilla)

Details

(Keywords: multiprocess)

Attachments

(1 file)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0
Build ID: 20170826053331

Steps to reproduce:

1. Check that multiprocess is enabled, check that middlemouse.contentLoadURL is enabled (default on "unix")
2. Visit about:neterror, about:blocked, about:certerror, about:invalidaboutpage, or e.g. a nonexistent domain http://this.domain.does.not.eggsist/ (which ought to land you in about:neterror)
3. Select any valid URL, then middle click on the visited page


Actual results:

No reaction to middle click.


Expected results:

The selected URL should start loading.
This is a regression caused by e10s.  Disabling e10s makes the middle click behave as it used to.

Bug 989875 is related.  The resolution there was to add onclick handlers that communicate with the remote page.  However the committed code only deals with the button elements on said pages.
Looking further, it is the handlers from bug 989875 in content.js/ClickEventHandler that actually cause this problem.  The surrounding code deals with Content:Click just fine, but the about page click handlers do their own thing and return early, thus not letting the rest of the code deal with middle clicks.  If I comment out the block, middle click behavior is restored.  As expected, this reintroduces the referenced problem with the dysfunctional buttons.

Is there any reason to let these about page buttons consume middle clicks?  If not, it seems that we can just not run said special handlers when clicked with anything that is not button 0.
Component: Untriaged → General
Keywords: multiprocess
Attachment #8904076 - Flags: review?(felipc)
Attachment #8904076 - Flags: review?(felipc) → review+
Keywords: checkin-needed
Assignee: nobody → mozilla
Pushed by ryanvm@gmail.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/b7e48e336d38
Run about pages' special click handlers only for button 0. r=felipe
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/b7e48e336d38
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 57
Flags: qe-verify+
Could you please elaborate on step 3?

If I use Firefox 57.0 beta 13, nothing happens at middle click with e10s enabled or disabled. I am opening about:neterror or http://this.domain.does.not.eggsist/ in a new tab, then I open a valid url in a second tab and I double click the url. After it is selected, I return to the first tab and I middle click inside it. The url from the second tab is not loaded. This works on Firefox 56.0.2 with e10s disabled.

Thank you!
Flags: needinfo?(mozilla)
(In reply to Petruta Rasa [QA] [:petruta] from comment #6)
> Could you please elaborate on step 3?
> 
> If I use Firefox 57.0 beta 13, nothing happens at middle click with e10s
> enabled or disabled. I am opening about:neterror or
> http://this.domain.does.not.eggsist/ in a new tab, then I open a valid url
> in a second tab and I double click the url. After it is selected, I return
> to the first tab and I middle click inside it. The url from the second tab
> is not loaded. This works on Firefox 56.0.2 with e10s disabled.
> 
> Thank you!

My first guess would be, recheck step 1.  The default value of middlemouse.contentLoadURL changed some time ago, and it is no longer enabled by default on any system.  After enabling that config option, behavior should be the same as on Firefox 56 with e10s disabled.
Flags: needinfo?(mozilla)
Thanks! I only verified on older versions where it was always true. 
I confirm the fix on Firefox 57 beta 14 under Ubuntu 16.04 LTS 64-bit.
Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.