Closed
Bug 966723
Opened 10 years ago
Closed 10 years ago
PanelUI button should quit customization on mouseup, not on mousedown
Categories
(Firefox :: Toolbars and Customization, enhancement)
Firefox
Toolbars and Customization
Tracking
()
VERIFIED
FIXED
Firefox 31
People
(Reporter: jaramat, Assigned: mikedeboer)
References
(Blocks 1 open bug)
Details
(Keywords: papercut, Whiteboard: [Australis:P4] [bugday-20140430])
Attachments
(1 file, 1 obsolete file)
3.15 KB,
patch
|
mconley
:
review+
lsblakk
:
approval-mozilla-aurora+
|
Details | Diff | Splinter Review |
Steps to reproduce: Enter Customization mode, move buttons around for a while, then try to move the PanelUI button on the right Expected result: Nothing happens, as long as the user holds down the mouse and tries to move the button (which cannot be moved, unfortunately and strangely enough) somewhere else; or maybe some kind of wiggle/shake effect or slide-down alert saying it's not possible to move the button Actual results: Customization mode closes itself on mouse down (before the mouse button is released), which may surprise/annoy the user This is a tiny change, but I think it may be for the best, because it's only logical that the user tries to move the button if they actually discover they can move buttons at all.
Updated•10 years ago
|
Blocks: australis-cust
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: papercut
Whiteboard: [Australis:P4]
Assignee | ||
Updated•10 years ago
|
Assignee: nobody → mdeboer
Status: NEW → ASSIGNED
Assignee | ||
Updated•10 years ago
|
OS: Windows 7 → All
Hardware: x86_64 → All
Assignee | ||
Comment 1•10 years ago
|
||
Attachment #8411781 -
Flags: review?(mconley)
Comment 2•10 years ago
|
||
Comment on attachment 8411781 [details] [diff] [review] Patch v1: exit Customize Mode on menu-button mouse-up >- case "mousedown": >+ case "mouseup": > if (aEvent.button == 0 && > (aEvent.originalTarget == this.window.PanelUI.menuButton)) { > this.exit(); > aEvent.preventDefault(); > return; > } > this._onMouseDown(aEvent); Calling _onMouseDown on mouseup doesn't look right. Also, why are you not using the command event?
Assignee | ||
Comment 3•10 years ago
|
||
Attachment #8411781 -
Attachment is obsolete: true
Attachment #8411781 -
Flags: review?(mconley)
Attachment #8411834 -
Flags: review?(dao)
Assignee | ||
Comment 4•10 years ago
|
||
Comment on attachment 8411834 [details] [diff] [review] Patch v1.1: exit Customize Mode on menu-button click Going back to Mike, like before! Dão, don't be sad, please feel free to do a drive-by like you did before!
Attachment #8411834 -
Flags: review?(dao) → review?(mconley)
Comment 5•10 years ago
|
||
Comment on attachment 8411834 [details] [diff] [review] Patch v1.1: exit Customize Mode on menu-button click Review of attachment 8411834 [details] [diff] [review]: ----------------------------------------------------------------- LGTM! Thanks mikedeboer!
Attachment #8411834 -
Flags: review?(mconley) → review+
Assignee | ||
Comment 6•10 years ago
|
||
Pushed as https://hg.mozilla.org/integration/fx-team/rev/df9f33c5a49d
Comment 7•10 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/df9f33c5a49d
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 31
Assignee | ||
Updated•10 years ago
|
Assignee | ||
Comment 8•10 years ago
|
||
Comment on attachment 8411834 [details] [diff] [review] Patch v1.1: exit Customize Mode on menu-button click [Approval Request Comment] Bug caused by (feature/regressing bug #): Australis User impact if declined: When user presses and holds the menu-button in Customization Mode with the mouse, as if to try and drag it to someplace else, it will exit Customization Mode right away. This patch makes it so that it'll only exit after a full click, so that the use can stay in this mode after releasing the mouse. Testing completed (on m-c, etc.): landed on m-c Risk to taking this patch (and alternatives if risky): minor String or IDL/UUID changes made by this patch: n/a
Attachment #8411834 -
Flags: approval-mozilla-aurora?
Updated•10 years ago
|
Attachment #8411834 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Assignee | ||
Comment 9•10 years ago
|
||
Please note that approval was granted for Fx 30, thus needs to be landed on beta, if I'm correct.
Keywords: checkin-needed
Updated•10 years ago
|
Keywords: checkin-needed
Whiteboard: [Australis:P4] → [Australis:P4][checkin-needed-beta]
Assignee | ||
Comment 10•10 years ago
|
||
Pushed to beta as: https://hg.mozilla.org/releases/mozilla-beta/rev/23481585e2e5
Assignee | ||
Updated•10 years ago
|
Whiteboard: [Australis:P4][checkin-needed-beta] → [Australis:P4]
Comment 11•10 years ago
|
||
Hi, I was able to reproduce it on Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0 ID:20140424030204 CSet: c8055a00235d in Debian Sid. I can confirm is no longer present in - latest Aurora Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0 ID:20140429004000 CSet: 4974d9da2f7d - latest Nightly Mozilla/5.0 (X11; Linux x86_64; rv:32.0) Gecko/20100101 Firefox/32.0 ID:20140429030201 CSet: d7c07694f339 (Still too early to verify Beta, the latest one still contain the problem)
status-firefox32:
--- → verified
Whiteboard: [Australis:P4] → [Australis:P4] [bugday-20140430]
Updated•10 years ago
|
status-b2g-v1.4:
--- → fixed
Comment 13•10 years ago
|
||
And now verified also on latest Beta Mozilla/5.0 (X11; Linux x86_64; rv:30.0) Gecko/20100101 Firefox/30.0 ID:20140512231802 CSet: 25886b573924. Cheers, Francesca
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•