Closed Bug 1109542 Opened 10 years ago Closed 9 years ago

[e10s] Middle click not working on about:about pages

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Version:
37 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
e10s m8+ ---

People

(Reporter: adalucinet, Assigned: mail, Mentored)

References

Details

Reproducible with latest Nightly 37.0a1 (Build ID: 20141209030205)
Platforms: Windows 7 64-bit, Windows 8.1 64-bit, Mac OS X 10.9.5 and Ubuntu 14.04 32-bit

Steps to reproduce:

1. Enter about:about in the URL bar.
2. Middle click on any link.

Expected results: The page is opened in a new tab.

Actual results: Nothing happens.

Notes:
1. Not reproducible with e10s disabled.
2. Reproducible also on about:about sub-pages.
Blocks: e10s
tracking-e10s: --- → ?
I also see this. Middle click on any internal interface is broken, including about:newtab.
Flags: firefox-backlog+
Assignee: nobody → mail
Mentor: jaws, mconley
Status: NEW → ASSIGNED
Hi Michael, do you have any questions that I can help you out with regards to this bug?
Flags: needinfo?(mail)
Hi Jared, 
Thanks for your message. After working on this bug for some time now, I actually do have some questions and I'd be thankful for any kind of help. 

What I did so far: 
- First I tried to make sure the click event is actually received by the page.
So I attached an event listener and logged the button attribute of the click event (snippet: https://pastebin.mozilla.org/8827541). When middle clicking on the links on the about:about page it correctly printed the button number 1.
- Next I tried to find the methods that evaluate the click and decide how to open it. 
I came across whereToOpenLink() (http://mxr.mozilla.org/mozilla-central/source/browser/base/content/utilityOverlay.js#116) and tried to find out when it is called using the debugger.
Even though it does get called when left clicking on a link or when middle clicking on pages outside the internal about:x pages, it is indeed not called when middle clicking on the links in about:about (and subpages). 
- The call stack of a "successful" whereToOpenLink() call looks like this (with e10s enabled)
  whereToOpenLink() (utilityOverlay.js)
  ContentClick.contentAreaClick (ContentClick.jsm)
  ContentClick.receiveMessage (ContentClick.jsm)

  (and like this with e10s disabled)
  whereToOpenLink (utilityOverlay.js)
  handleLinkClick (browser.js)
  contentAreaClick (browser.js)

but unfortunately not even the receiveMessage function gets called when middle clicking on the links in about:x. 
- Since ContentClick.receiveMessage() is the bottom of the call stack I don't really know how to find out when who calls this method (and why it's not called in our case). I tried to use the freetext search for the term but wasn't very successful in narrowing down the problem and finding relevant files. 

What would you suggest is the best way to find out why the receiveMessage method is not called? Or am I maybe on the wrong track? 

Thanks a lot for your help! :-)
Best regards,
Michael
Flags: needinfo?(mail)
Skipping internal details, receiveMessage is called after sendAsyncMessage is called. It allows content scripts to communicate with chrome scripts. The "Content:Click" async message is sent from handleEvent at http://mxr.mozilla.org/mozilla-central/source/browser/base/content/content.js#654

You may be able to walk through the code there to get further in your investigation.
Thanks for the info regarding sendAsyncMessage and handleEvent. 

Strangely enough, the handleEvent seems to not always be called correctly (or called at all) when e10s is enabled. 
I used the Browser Toolbox and also the Browser Content Toolbox, set a breakpoint in handleEvent (http://mxr.mozilla.org/mozilla-central/source/browser/base/content/content.js#655), and tried to see if the debugger halts correctly. What I found out: 
Using Browser Toolbox: 
- Non-e10s window (both on about:about + subpages and on other "external" sites): The debugger halts in handleEvent when a normal left click is performed. HandleEvent does not get called on right or middle click though.
- e10s window (both on about:about + subpages and on other "external" sites): The debugger does not halt in handleClick at all, no matter what kind of click is performed. Maybe the click event is sent to the wrong process because the page is remote (see below)?!

Using Browser Content Toolbox: 
- e10s window on "external" pages: Debugger halts on all kind of clicks (left, middle, right).
- e10s window on about:about on subpages: Debugger does not halt at all,  no matter what kind of click is performed. 


This seems very strange to me, since handleEvent seems to be the only method that sends the "Content:Click" async message. But where else does the ContentClick.receiveMessage() receive its message from in the cases handleEvent is not called?  

Any kind of help is appreciated.  :-)
Flags: needinfo?(mconley)
I've actually been mucking about in EventStateManager today, so I'll see if I can trace what's going on here. I'll hopefully have some explanation up in an hour or so.
Hey Michael - thanks for your analysis - it helped me drill down to what is going on.

Basically, it looks like something is going wrong with dispatching middle or right-click events to content scripts via the system event listener service when running in a non-remote browser. Left clicks seems to be OK.

I've added a regression test to the bug, and hopefully we'll come up with a solution there soon. Once that's unblocked, we can guide you through the rest of this (it should hopefully be more straight forward!). Until then, you might want to select a different bug from bugs ahoy? Perhaps bug 1072371?
Flags: needinfo?(mconley)
Typo from comment #9 fixed below,

(In reply to Mike Conley (:mconley) - Needinfo me! from comment #9)
> Michael,
> 
> Actually, it looks like bug 1150709 is going to get fixed faster than I
> thought! There's already a reviewed patch in there. Once that lands, let's
> see where we are!
> 
> (Alternatively, you could apply billm's patch in bug 1150709 right now in
> your local build and see if it works for you - then you could see if the
> click handler is being received in content.js. If so, we can probably just
> get rid of the contentAreaClick handler in browser.js).
Hey Michael,

With bug 1150709 fixed now, are you OK to keep hacking on this?
Flags: needinfo?(mail)
Hello Mike and Jared,

Great to hear that bug 1150709 is fixed now. Of course I'd love to continue working on this bug and will most likely find time for it tonight.  

Best,
Michael
Flags: needinfo?(mail)
Great! Let us know if you have any questions.
Thanks for the information, Jared!
I'm sorry that it took me some time to get back to this.

Interestingly enough, as far as I can tell, the middle click on about:about (and its subpages) seems to be working now. I guess, fixing bug 1150709 and thus correctly receiving the middle click event did the trick. 

I just stepped it through with the debugger and whereToOpenLink() now gets successfully called and returns "tab" on middle click, causing the links to correctly open up in a new tab. 

Do you consider this bug to be fixed or is there another aspect that might be improved regarding the middle click on about:about (and its subpages)?

Best,
Michael
Yes, WFM in Nightly 40.0a1 (2015-04-19) on Windows 7.
about:
about:licenses
about:buildconfig
all links react to middle clicks.
Michael, no worries! Let's find you something else to work on...

Mike/Jared, looks like this is WFM - can either of you suggest a different bug for Michael to work on? I've been looking, but I've not found appropriately-marked mentored bugs on e10s or other things that seem related.
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Flags: needinfo?(mconley)
Flags: needinfo?(jaws)
Resolution: --- → WORKSFORME
Perhaps bug 1099491, which sounds like it's in the same ballpark as this bug? Michael, does bug 1099491 sound interesting to you?
Flags: needinfo?(mconley) → needinfo?(mail)
Hi Mike, 
Sorry for the delay. Bug 1099491 sounds very interesting to me and I'd love to work on it!
Flags: needinfo?(mail)
Alright - I've assigned you that bug.
Flags: needinfo?(jaws)
You need to log in before you can comment on or make changes to this bug.