[e10s] DoubleClicking a select doesn't collapse when clicking on the dropmarker

RESOLVED FIXED in Firefox 51

Status

()

P1
normal
RESOLVED FIXED
3 years ago
2 years ago

People

(Reporter: arni2033, Assigned: enndeakin)

Tracking

(Blocks: 1 bug)

Trunk
mozilla51
All
Windows
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(e10s+, firefox43 affected, firefox51 fixed)

Details

(Whiteboard: e10st?, URL)

Attachments

(3 attachments)

(Reporter)

Description

3 years ago
STR:   (Win7, Nightly 43.0a1 (2015-08-12))
1. Open     https://bug1186972.bmoattachments.org/attachment.cgi?id=8638018 (attachment on bug 1186972)
   OR page  data:text/html,<select><option>First<option>Second
2. DoubleClick on dropmarker

Result:       The drop-down list hasn't collapsed
Expectations: It should've collapsed

// I have mentioned this in comments bug 1186972 comment 8, bug 1186972 comment 10
A double click is just the same as clicking it twice.  It will open, then close or close, then open depending on starting state.  This is how it works on Release.  And Nightly e10s performs exactly the same.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → INVALID
(Reporter)

Comment 2

3 years ago
Created attachment 8647559 [details]
[e10s] DoubleClicking a select doesn't collapse when clicking on the dropmarker.webm

Please watch the video and tell what OS have you used for the testing
Flags: needinfo?(twalker)
Ah, my apologies. So the start state is closed, then in the end it doesn't close for you.  I am on Mac OSX.  In the video, are you doing a third click away from the select item?  (making it close)
Status: RESOLVED → REOPENED
Flags: needinfo?(twalker)
OS: Unspecified → Windows
Hardware: Unspecified → All
Resolution: INVALID → ---
(Reporter)

Comment 4

3 years ago
(In reply to [:tracy] Tracy Walker - QA Mentor from comment #3)
> In the video, are you doing a third click away from the select item?  (making it close)
Yes, on the video I wait a bit, then click on the free area to show the issue again

Updated

3 years ago
Status: REOPENED → NEW
tracking-e10s: --- → ?

Updated

3 years ago
tracking-e10s: ? → +
(Reporter)

Updated

3 years ago
Depends on: 1186972

Updated

3 years ago
Blocks: 516752
(Reporter)

Updated

3 years ago
Has STR: --- → yes
(Reporter)

Updated

3 years ago
Blocks: 1154677
User Agent 	Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:46.0) Gecko/20100101 Firefox/46.0
Build ID 	20160207004019

Tested on Windows 7 x64 with the Aurora 46.0a2 build. With e10s enabled, I can sometimes reproduce the problem. With e10s disabled, the issue does not reproduce.

Updated

3 years ago
Priority: -- → P1

Updated

2 years ago
Whiteboard: e10st?
(Assignee)

Comment 6

2 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)

Comment 7

2 years ago
Oops, that comment was meant for bug 1253979.

The comment for this bug is:

The non-e10s is case toggles the list open state within nsListControlFrame::MouseDown, however e10s only opens it. So might be able to fix this by using a message which toggles the state rather than only opens it.
This is a Windows-only bug. On Mac and Linux, the 2nd click in a double click is handled like a single click and short-circuit to nsXULPopupManager::Rollup() from nsWindow::CheckForRollup() (Linux) and [ChildView maybeRollup] (Mac). I guess we can do likewise in nsWIndow::DealWithPopups().
Created attachment 8772361 [details] [diff] [review]
bug_1194027.patch
Attachment #8772361 - Flags: feedback?(enndeakin)
(Assignee)

Comment 11

2 years ago
Comment on attachment 8772361 [details] [diff] [review]
bug_1194027.patch

This will cause all popups to rollup on double-click which we don't want to do in general.
Attachment #8772361 - Flags: feedback?(enndeakin) → feedback-
(Assignee)

Updated

2 years ago
Assignee: nobody → enndeakin
Status: NEW → ASSIGNED
(Assignee)

Comment 12

2 years ago
Created attachment 8774826 [details] [diff] [review]
Add a chrome-only flag to select used to track if the parent process popup is open

You'll need 1159301 if you want to apply the test part of the patch.
Attachment #8774826 - Flags: review?(mrbkap)
(Assignee)

Updated

2 years ago
Blocks: 1253979

Updated

2 years ago
Attachment #8774826 - Flags: review?(mrbkap) → review+
(Assignee)

Comment 13

2 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/69b3a93aeba57617eaa4c579bea5c78f343c7d43
Bug 1194027, add a flag to select elements to indicate if the parent process has the popup open, r=mrbkap

Comment 14

2 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/69b3a93aeba5
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago2 years ago
status-firefox51: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla51
(Assignee)

Updated

2 years ago
Blocks: 1289528
(Assignee)

Comment 15

2 years ago
I didn't include the test for this patch as it was failing intermittently on Windows.
(Reporter)

Updated

2 years ago
See Also: → bug 1327149
You need to log in before you can comment on or make changes to this bug.