Ensure the matched tab isn't over the search box in the Panorama UI

VERIFIED FIXED in Firefox 4.0b8

Status

Firefox Graveyard
Panorama
P2
normal
VERIFIED FIXED
7 years ago
a year ago

People

(Reporter: raymondlee, Assigned: Sean Dunn)

Tracking

unspecified
Firefox 4.0b8
Dependency tree / graph

Details

(Whiteboard: [visual])

Attachments

(1 attachment, 2 obsolete attachments)

8.19 KB, patch
Details | Diff | Splinter Review
Comment hidden (empty)
(Reporter)

Updated

7 years ago
Depends on: 592045
Assigning to Aza for ux/design opinion.
Assignee: nobody → aza
Priority: -- → P4

Comment 2

7 years ago
Not sure why this is assigned to me as I wrote the bug ;)

The right solution is that the search box floats over all.
Priority: P4 → P2
Whiteboard: [visual]
Target Milestone: --- → Firefox 4.0
Assignee: aza → seanedunn
Blocks: 598154

Updated

7 years ago
Duplicate of this bug: 599484

Comment 4

7 years ago
Sean, take a look at bug 599484 for some extra info on what (I think) might be happening.
(Assignee)

Comment 5

7 years ago
Created attachment 482755 [details] [diff] [review]
v1

Solution was to make the shaded area of the search be a different DIV (#searchshade), at the same level as the tabs and #search DIV. Since CSS follows stacking context rules, you can't place an element between two other elements, if those two elements are in a separate stacking context, and all elements are absolutely positioned with a z-index set. 

Also took out an ad-hoc z-index setting that wasn't doing anything, and set #search to let mouse clicks pass through it.
Attachment #482755 - Flags: feedback?(ian)
Comment on attachment 482755 [details] [diff] [review]
v1

Lovely!
Attachment #482755 - Flags: review?(dietrich)
Attachment #482755 - Flags: feedback?(ian)
Attachment #482755 - Flags: feedback+
Comment on attachment 482755 [details] [diff] [review]
v1

Switching review to dolske, as dietrich says he's not reviewing non-blockers for the time being.
Attachment #482755 - Flags: review?(dietrich) → review?(dolske)
(Reporter)

Updated

7 years ago
Status: NEW → ASSIGNED
Attachment #482755 - Flags: review?(dolske) → review+
Comment on attachment 482755 [details] [diff] [review]
v1

Sean, please update for check-in. Also, does this patch need to go through try?
Attachment #482755 - Flags: approval2.0?
(Assignee)

Comment 9

7 years ago
Created attachment 489820 [details] [diff] [review]
v2

Pushed to try: http://hg.mozilla.org/try/rev/d5b513808a08
Attachment #482755 - Attachment is obsolete: true
Attachment #482755 - Flags: approval2.0?
(Assignee)

Comment 10

7 years ago
Try passed.
Comment on attachment 489820 [details] [diff] [review]
v2

Sorry, jumped the gun; didn't yet have approval.
Attachment #489820 - Flags: approval2.0?
Comment on attachment 489820 [details] [diff] [review]
v2

a=beltzner, wondering if this should actually block
Attachment #489820 - Flags: approval2.0? → approval2.0+
blocking2.0: --- → final+
Sean, please unrot this patch. Also, rather than "a-2.0+f=ian" in the commit message, it should be "a=blocking" (I don't have authority to approve or block).
(Assignee)

Comment 14

7 years ago
Created attachment 494078 [details] [diff] [review]
v3 (for check-in)

Unrotted
Attachment #489820 - Attachment is obsolete: true
(Assignee)

Updated

7 years ago
Keywords: checkin-needed
http://hg.mozilla.org/mozilla-central/rev/918e77b79312
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: Firefox 4.0 → Firefox 4.0b8
Verified in recent nightly minefield build
Status: RESOLVED → VERIFIED
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.