Closed
Bug 413819
Opened 17 years ago
Closed 17 years ago
Autocomplete dropmarker should always stay in hovered state when menu is opened using the dropdown button
Categories
(Firefox :: Address Bar, defect)
Firefox
Address Bar
Tracking
()
RESOLVED
FIXED
Firefox 3 beta4
People
(Reporter: chadwickgab+mozilla, Assigned: dao)
References
Details
(Keywords: polish)
Attachments
(1 file, 1 obsolete file)
1.42 KB,
patch
|
Gavin
:
review+
mtschrep
:
approval1.9b3-
mtschrep
:
approval1.9+
|
Details | Diff | Splinter Review |
Steps to reproduce
1. Open the adress bar menu with the dropdown button.
2. Move mouse to an other place then the drop down button.
Actual behavior :
The dropdown button is not in hovered state.
Expected behavior :
The dropdown button should stay in hovered state until menu close. This behavior is what IE and windows vista does... It give better indication that the action of the button is still there.
Flags: blocking-firefox3?
Assignee | ||
Comment 1•17 years ago
|
||
Ideally, I think we would use the :active pseudo class for this, but it's not set as the popup is open. The second option is to use [open="true"], but the "open" attribute isn't set consistently in autocomplete.xml.
Reporter | ||
Updated•17 years ago
|
Summary: Autocomplete dropmarker should always stay in hovered state when menu is opened use the dropdown button → Autocomplete dropmarker should always stay in hovered state when menu is opened using the dropdown button
Version: 2.0 Branch → Trunk
Assignee | ||
Comment 2•17 years ago
|
||
Assignee | ||
Comment 3•17 years ago
|
||
Moved the attribute selector to the dropmarker. Doesn't make a difference, it's only better readable.
Attachment #301061 -
Attachment is obsolete: true
Attachment #301132 -
Flags: review?(gavin.sharp)
Attachment #301061 -
Flags: review?(gavin.sharp)
Updated•17 years ago
|
Attachment #301132 -
Flags: review?(gavin.sharp) → review+
Assignee | ||
Updated•17 years ago
|
Attachment #301132 -
Flags: approval1.9b3?
Attachment #301132 -
Flags: approval1.9?
Comment 4•17 years ago
|
||
Comment on attachment 301132 [details] [diff] [review]
patch
I know this patch is trivial but no reason why it can't wait for b4.
Attachment #301132 -
Flags: approval1.9b3?
Attachment #301132 -
Flags: approval1.9b3-
Attachment #301132 -
Flags: approval1.9?
Attachment #301132 -
Flags: approval1.9+
Updated•17 years ago
|
Keywords: checkin-needed
Updated•17 years ago
|
Updated•17 years ago
|
Keywords: checkin-needed
Comment 5•17 years ago
|
||
Checking in browser/themes/winstripe/browser/browser.css;
/cvsroot/mozilla/browser/themes/winstripe/browser/browser.css,v <-- browser.css
new revision: 1.168; previous revision: 1.167
done
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3 beta4
Reporter | ||
Comment 6•17 years ago
|
||
This does not look fixed on Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9b4pre) Gecko/2008020708 Minefield/3.0b4pre ID:2008020708 Am I not using the good build ?
Assignee | ||
Comment 7•17 years ago
|
||
This depends on bug 414845, which needs a new patch.
You need to log in
before you can comment on or make changes to this bug.
Description
•