618828 - Cannot access search results from secondary window via click

Status: VERIFIED FIXED

(Firefox Graveyard :: Panorama, defect, P2)

Description

[Maniac Vlad Florin (:vladmaniac)]

Build ID: 

Mozilla/5.0 (Windows NT 6.1; rv:2.0b8pre) Gecko/20101212 Firefox/4.0b8pre

Steps: 

1. Make sure you have some browsed content in a few tabs 
2. Open a site (e.g. www.yahoo.com) in a new window
3. Bring up panorama and search for "yahoo" 

Behavior: 
You should see the result in the bottom of the screen, as a tab from another window. Clicking on the result does not direct you to the specific page. 

This bug is a regression from bug 598691, and was filed due to 

https://bugzilla.mozilla.org/show_bug.cgi?id=598691#c11

Comment 1

[juan becerra [:juanb]]

Nominating because it is a recent regression of functionality that had been granted blocking2.0 in its previous incarnation.

Comment 2

[Tim Taubert [:ttaubert] (inactive)]

Attachment: patch v1

Comment 3

[Tim Taubert [:ttaubert] (inactive)]

v1 + v2.6 from bug 610242 pushed to try today. Passed.

Comment 4

[Ian Gilman [:iangilman]]

Comment on attachment 501907 [details] [diff] [review]
patch v1

> #searchbox{
>   position: absolute;
>   right: 20px;
>   top: 20px;
>+  pointer-events: auto;
> }

Forgive my ignorance, but how does this fix it?

At any rate, since it seems to, I'm all for it.

Comment 5

[Tim Taubert [:ttaubert] (inactive)]

(In reply to comment #4)
> Comment on attachment 501907 [details] [diff] [review]
> Forgive my ignorance, but how does this fix it?

#search { pointer-events: none; }

This was the original state added with bug 594433.

Citing from https://developer.mozilla.org/en/CSS/pointer-events

"none - The element is never the target of mouse events, although mouse events may target its descendant elements if those descendants have pointer-events set to some other value, in which case mouse events will trigger event listeners on this element as appropriate on their way to/from the descendant during the event capture/bubble phases."

So after reading this it got clear that the clickable elements #searchbox and #results>.inlineMatch (descendants of #search) needed to be set to at least 'pointer-events: auto' to be clickable targets again. I had a quick look at tabview.css when starting to investigate this bug and was curious about what 'pointer-events' is :)

Comment 6

[Ian Gilman [:iangilman]]

Comment on attachment 501907 [details] [diff] [review]
patch v1

Interesting! Thanks. 

Btw, this bug is a blocker, so it doesn't need approval (blocking is like pre-approval); please package for landing!

Comment 7

[Tim Taubert [:ttaubert] (inactive)]

Attachment: patch v2 (for checkin)

Comment 8

[Tim Taubert [:ttaubert] (inactive)]

Attachment: patch v2 (for checkin)

Comment 9

[Kevin Hanes]

bugspam (moving b9 to b10)

Comment 10

[Kevin Hanes]

bugspam (removing b9)

Comment 11

[Ian Gilman [:iangilman]]

http://hg.mozilla.org/mozilla-central/rev/62e195a65ff3

Comment 12

[Andreea Pod]

Build identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b9) Gecko/20100101 Firefox/4.0b9

This bug is still reproducible.

Comment 13

[Andreea Pod]

If you are in private browsing, sorry i forgot to mention.

Comment 14

[Tim Taubert [:ttaubert] (inactive)]

Works for me in normal and private mode (using trunk version). This patch is not included in b9 but will be in b10.

Comment 15

[Maniac Vlad Florin (:vladmaniac)]

This is verified on 

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b10) Gecko/20100101 Firefox/4.0b10