e10s breaks middlemouse.contentLoadURL on internal error pages

VERIFIED FIXED in Firefox 57

Status

()

Firefox
General
VERIFIED FIXED
3 months ago
13 days ago

People

(Reporter: Henri Kemppainen, Assigned: Henri Kemppainen)

Tracking

({multiprocess})

55 Branch
Firefox 57
multiprocess
Points:
---

Firefox Tracking Flags

(firefox57 verified)

Details

Attachments

(1 attachment)

(Assignee)

Description

3 months ago
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.
(Assignee)

Comment 1

3 months ago
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.
(Assignee)

Comment 2

3 months ago
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.
(Assignee)

Comment 3

3 months ago
Created attachment 8904076 [details] [diff] [review]
aboutpage-middlebutton-fix.patch

Updated

3 months ago
Component: Untriaged → General
Keywords: multiprocess
(Assignee)

Updated

3 months ago
Attachment #8904076 - Flags: review?(felipc)
Attachment #8904076 - Flags: review?(felipc) → review+
(Assignee)

Updated

2 months ago
Keywords: checkin-needed
Assignee: nobody → mozilla

Comment 4

2 months ago
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
Last Resolved: 2 months ago
status-firefox57: --- → fixed
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)
(Assignee)

Comment 7

14 days ago
(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
status-firefox57: fixed → verified
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.