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)

defect

Tracking

()

RESOLVED FIXED
mozilla51
Tracking Status
e10s + ---
firefox47 --- affected
firefox51 --- fixed

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
Attached image select behavior
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
does this block?
Flags: needinfo?(jgriffiths)
(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
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)
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)
Oh, yes. This IS only visual issue. It doesn't result in values getting selected
See Also: → 1256313
Whiteboard: e10st?
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.
Blocks: 1264271
Assignee: nobody → enndeakin
Status: NEW → ASSIGNED
Depends on: 1194027
This patch uses the feature added by bug 1194027.
Attachment #8774827 - Flags: review?(jmathies)
Attachment #8774827 - Flags: review?(jmathies) → review+
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
Whiteboard: e10st?
https://hg.mozilla.org/mozilla-central/rev/417d1e27c8ea
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla51
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: