Closed
Bug 1253979
Opened 8 years ago
Closed 8 years ago
[e10s] <select> preserves depressed state of dropmarker and stays active when I release mouse over the list of options [2/3]
Categories
(Core :: Layout: Form Controls, defect, P1)
Core
Layout: Form Controls
Tracking
()
RESOLVED
FIXED
mozilla51
People
(Reporter: arni2033, Assigned: enndeakin)
References
(Blocks 1 open bug)
Details
Attachments
(3 files)
>>> My Info: Win7_64, Nightly 47, 32bit, ID 20160229030448. DEFAULT THEME
STR (A),(B):
1. Open attached "testcase 1"
2. Hover mouse over the <select>'s dropmarker, hold left mouse button [drop-down list will open]
3.A) Hover mouse over any visible option
3.B) Hover mouse over option the upper scroll button in scrollbar
4. Release left mouse button
STR (C),(D):
1. Open attached "testcase 1"
2. Click the <select>'s dropmarker [drop-down list will open]
3.C) Hover mouse over any visible option. Click left mouse button.
3.D) Hover mouse over option the upper scroll button in scrollbar.
AR:
(A) Option from Step 3 is selected, but dropmarker is still in "depressed" state
(C) Option from Step 3 is selected, and dropmarker is black arrow on white background
(B) Mouse is hovering the upper scroll button, but dropmarker is still in "depressed" state
(D) Mouse is hovering the upper scroll button, and dropmarker is black arrow on white background
ER:
Scenarios (A) and (C) should result in the same dropmarker state.
Scenarios (B) and (D) should result in the same dropmarker state.
Note:
"Depressed state" means black arrow on dark-blue background.
Request a screenshot/screencast if necessary
Comment hidden (spam) |
Comment 2•8 years ago
|
||
You did it all wrong! The screenshot is irrelevant. There're 8 scenarios to compare in comment 0. You should believe those who does the actual testing. <select> is completely broken for years v_v
Comment 5•8 years ago
|
||
(In reply to Jim Mathies [:jimm] from comment #4) > does this block? This should block. My reasoning is, if you open the list, hover over a value and then mouse out + hit enter two times to submit the form, the submitted value for the list is *different* between e10s and non-e10s. My rational that I'm trying to be consistent with is that if the behaviour of the content is different, then we should block. If there is only a visible difference, we should not block but catch the bug as high priority during a polish sprint.
Flags: needinfo?(jgriffiths) → needinfo?(jmathies)
Priority: -- → P1
Comment hidden (obsolete) |
Comment 7•8 years ago
|
||
Lets try to report just one bug per report here, but first let me try to understand what you're seeing. The one bug reported here that I can reproduce easily is the following: bug #1: 1. Open attached "testcase 1" 2. Place mouse over the <select>'s dropmarker, click down and hold the left mouse button [drop-down list will open] 3. move mouse to any visible option 4. Release left mouse button Issue: the bug here is that the drop marker remains painted as "hot" or "selected" bug #2: 1. Open attached "testcase 1" 2. Click the <select>'s dropmarker [drop-down list will open] 3. Move mouse to the scroll scrollbar. 4) release mouse button issue: no item selected in the select. drop marker states seems about the same.
Flags: needinfo?(jmathies) → needinfo?(arni2033)
Comment 8•8 years ago
|
||
s/one bug/two bugs Note, minor differences in the drop marker state behavior are very polishy in nature. Once we switch to e10s for everyone, it won't make much difference what the old behavior was. So what we're looking for here is behavioral issues in selection that could result in different values getting selected through the same steps.
(In reply to Jim Mathies [:jimm] from comment #7) > Lets try to report just one bug per report here I filed comment 6 as bug 1256313. Comment 5 is bug 1197913. > The two bugs reported here that I can reproduce easily is the following: Yes, everything is described correctly. Those 2 are scenarios (A) and (B) in e10s mode. Except "click" is "mousedown-mouseup", while in my STR only "mousedown" should happen in Step 2. I think you still meant "hold" instead of "click". (In reply to Jim Mathies [:jimm] from comment #8) > Once we switch to e10s for everyone, it won't make much difference what the old behavior was I haven't said that e10s behavior must be the same. <select>'s button could as well _always_ look not hovered and not pressed, like in GoogleChrome... But IMO the best way to fix this is indeed to display "not hovered" button (black dropmarker on white) What I reported is, exactly: <select>'s visual appearance should only take into account: 1) if drop-down list is opened or not 2) if <select> is focused or not 3) mouse position (hovered/not hovered) 4) mouse state (which mouse buttons are pressed) I hope that everybody will agree that this logic should be fulfilled. Scenarios (A) and (C) are identical in the logic above. So each of them should result in the same visual appearance of <select>. The same for (B) vs (D).
Flags: needinfo?(arni2033)
Reporter | ||
Comment 10•8 years ago
|
||
Oh, yes. This IS only visual issue. It doesn't result in values getting selected
See Also: → 1256313
Updated•8 years ago
|
tracking-e10s:
--- → +
Updated•8 years ago
|
Blocks: e10s-select
Updated•8 years ago
|
Whiteboard: e10st?
Assignee | ||
Comment 11•8 years ago
|
||
The issue here is in the NS_THEME_MENULIST_BUTTON block of nsNativeThemeWin::GetThemePartAndState IsDroppedDown() is called but will never return true in e10s since we don't set the flag used by it. The code here inside the IsVistaOrLater() block is a little odd in that it doesn't handle the non-open case and just falls through. In non-e10s you can see odd behaviour if you hold the mouse on the drop marker, then press escape, then move the mouse slightly -- the active state only appears then and no other time. So I don't think this code is correct as is anyway, but we probably will still need an IsDroppedDown method that returns the correct state.
Assignee | ||
Updated•8 years ago
|
Assignee: nobody → enndeakin
Status: NEW → ASSIGNED
Assignee | ||
Comment 12•8 years ago
|
||
This patch uses the feature added by bug 1194027.
Assignee | ||
Updated•8 years ago
|
Attachment #8774827 -
Flags: review?(jmathies)
Updated•8 years ago
|
Attachment #8774827 -
Flags: review?(jmathies) → review+
Assignee | ||
Comment 13•8 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/417d1e27c8eaf63a737abd95cc26d912332f232f Bug 1253979, use remote open state for select elements in theme to ensure active state is correct, r=jimm
Updated•8 years ago
|
Whiteboard: e10st?
Comment 14•8 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/417d1e27c8ea
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
status-firefox51:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla51
You need to log in
before you can comment on or make changes to this bug.
Description
•