Closed
Bug 561064
Opened 14 years ago
Closed 14 years ago
Larry menu doesn't work correctly when finger is dragged from the Larry menu to awesome bar url field
Categories
(Firefox for Android Graveyard :: General, defect)
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: kayttajanimi, Assigned: vingtetun)
Details
Attachments
(1 file)
844 bytes,
patch
|
mfinkle
:
review+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.11) Gecko/2009060309 Ubuntu/8.04 (hardy) Firefox/3.0.11 Build Identifier: Mozilla/5.0 (X11; U;Linux armv71; en-US; rv:1.9.2.5pre) Gecko/20100420 Namroka/3.6.5pre Fennec/1.1a2pre When finger is dragged from Larry menu to awesome bar url field, the focus moves to url field and menu disappears. Button on the awesome bar for Larry menu stays toggled like the menu would be visible still. If you click that button it will come untoggled and only after second click you get the Larry menu to be visible again. Reproducible: Always Steps to Reproduce: 1. Open Larry menu 2. Drag your finger from the menu to awesome bar url field 3. Release your finger. Actual Results: Button for Larry bar stays toggled even though menu is not visible anymore. Expected Results: Button for Larry bar should follow state changes correctly. Most likely this bug caused because it is not expected that focus would change to url field when dragged, so that would be the real bug behind this.
Reporter | ||
Updated•14 years ago
|
Hardware: Other → ARM
Version: Trunk → 1.9.2 Branch
Assignee | ||
Comment 1•14 years ago
|
||
Thanks for the full of details bug report, it helps me figured what's wrong quickly!
> Most likely this bug caused because it is not expected that focus would change
> to url field when dragged, so that would be the real bug behind this.
To be exact, the "site menu" and many dialogs in Fennec are supposed to dismiss when you do something else. With that in mind we were checking if, during a "mousedown" the target is different than the "dialog" (and a few others stuff) and if it is the case just dismiss the dialog.
But in your testcase you're doing the mousedown on an authorized target and the mouseup on another non-authorized one.
patch is coming.
Thanks again.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee | ||
Comment 2•14 years ago
|
||
This patch add a check for the event target during mouseup.
Assignee: nobody → 21
Attachment #440766 -
Flags: review?(mark.finkle)
Updated•14 years ago
|
Attachment #440766 -
Flags: review?(mark.finkle) → review+
Comment 3•14 years ago
|
||
pushed: http://hg.mozilla.org/mobile-browser/rev/c4b7585c7d64
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Comment 4•14 years ago
|
||
Cool! verified FIXED on build: Mozilla/5.0 (X11; U; Linux armv7l; Nokia N900; en-US; rv:1.9.2.5pre) Gecko/20100423 Namoroka/3.6.5pre Fennec/1.1a2pre
Status: RESOLVED → VERIFIED
Flags: in-litmus?
Updated•14 years ago
|
Component: Linux/Maemo → General
OS: Linux → Linux (embedded)
QA Contact: maemo-linux → general
Updated•14 years ago
|
Assignee: 21 → mozaakash
Updated•14 years ago
|
Assignee: mozaakash → 21
Flags: in-litmus? → in-litmus?(mozaakash)
Comment 5•14 years ago
|
||
litmus testcase https://litmus.mozilla.org/show_test.cgi?id=12932 created to regression test this bug.
Flags: in-litmus?(mozaakash) → in-litmus+
You need to log in
before you can comment on or make changes to this bug.
Description
•