Closed
Bug 618248
Opened 15 years ago
Closed 15 years ago
When I start drag a bookmark in any Bookmarks popup, the Bookmarks popup closes immediately
Categories
(Core :: Widget: Gtk, defect)
Tracking
()
RESOLVED
FIXED
mozilla2.0b9
| Tracking | Status | |
|---|---|---|
| blocking2.0 | --- | final+ |
People
(Reporter: alice0775, Assigned: enndeakin)
References
Details
(Keywords: regression)
Attachments
(1 file, 1 obsolete file)
|
1.55 KB,
patch
|
karlt
:
review+
|
Details | Diff | Splinter Review |
Build Identifier:
Mozilla/5.0 (X11; Linux i686; rv:2.0b8pre) Gecko/20101209 Firefox/4.0b8pre ID:20101209030340
See http://forums.mozillazine.org/viewtopic.php?p=10205813#p10205813
When I drag start a bookmark in any Bookmarks popup, the Bookmarks popup closes immediately.
And This does not happen Windows build.
Reproducible: Always
Steps to Reproduce:
1. Start Minefield with new profile
2. drag start a bookmark in any Bookmarks popup(Bookmarks in Menubar, Bookmarks toolbar, Chevron, Firefox Button)
3.
Actual Results:
When I drag start a bookmark in any Bookmarks popup, the Bookmarks popup closes immediately.
And leaves that bookmark visible.
Expected Results:
Bookmarks popup should not hide.
Regression window:
Works:
http://hg.mozilla.org/mozilla-central/rev/f38ef1080bfe
Mozilla/5.0 (X11; Linux i686; rv:2.0b7pre) Gecko/20100916 Firefox/4.0b7pre ID:20100916030125
Fails:
http://hg.mozilla.org/mozilla-central/rev/268ef4ccb5ff
Mozilla/5.0 (X11; Linux i686; rv:2.0b7pre) Gecko/20100917 Firefox/4.0b7pre ID:20100917034123
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f38ef1080bfe&tochange=268ef4ccb5ff
In local build:
Build from
4097291a632c : Fails
5a68532076bf : Works
Regressd by 4097291a632c Neil Deakin — Bug 522956 - Clicking Larry's "More Information" button opens Page Info dialog but doesn't close Larry. r=karlt a=b
| Reporter | ||
Updated•15 years ago
|
blocking2.0: --- → ?
Assignee: nobody → enndeakin
blocking2.0: ? → final+
| Assignee | ||
Comment 1•15 years ago
|
||
Looks like a focus-out event occurs when a drag begins, causing the popup to rollup.
| Assignee | ||
Comment 2•15 years ago
|
||
Karl, do you know why this might happen?
Comment 3•15 years ago
|
||
Versions of GTK prior to 2.18 (somewhere around Oct 2009) grabbed the keyboard
during a drag. Grabbing the keyboard moves focus.
http://git.gnome.org/browse/gtk+/commit/?h=gtk-2-18&id=c981ddf92ff234321d4fb9f51e58698dba507c3d
At the X11 protocol level Focus events due to grabs are distinguishable from
normal focus events, however GDK does not provide this distinction.
http://tronche.com/gui/x/xlib/events/input-focus/grab.html
With more recent GTK (2.20.1 here), the behaviour I see is that the menu
closes when the pointer leaves the menu. If that is the expected behavior
(and it seems reasonable to me), then we may wish to reconsider the importance
of this bug.
Comment 4•15 years ago
|
||
As for a fix, possibly OnContainerFocusOutEvent could skip check_for_rollup if a drag is in progress. I haven't really thought through possible issues from async events, and whether or not rollup should be performed on drag completion.
| Assignee | ||
Comment 5•15 years ago
|
||
The bookmarks code handles closing the popup itself. It closes the popup manually when dragging outside of it and any descendants. It doesn't expect the popup to close automatically while dragging.
| Assignee | ||
Comment 6•15 years ago
|
||
After talking with Marco a bit, I realized that description wasn't quite correct.
The ideal behaviour is that the popup closes when dragging outside of it. But special cases may need to occur when a submenu is involved. For example, dragging from a submenu to a parent menu should close the submenu but keep the parent open. Similarly, dragging to a submenu should keep both open.
I will try a patch that implements comment 4.
| Assignee | ||
Comment 7•15 years ago
|
||
Attachment #497324 -
Flags: review?(karlt)
| Assignee | ||
Updated•15 years ago
|
Whiteboard: [has patch][needs review karl]
Comment 8•15 years ago
|
||
Comment on attachment 497324 [details] [diff] [review]
Patch
I think we still want to check_for_rollup if the focus changes during a drag started in another application (Another application may begin a drag without taking focus), and it is easy enough to check for same-application drag with nsIDragSession::GetSourceNode (or you may know a better way), so I think it's best that we do that.
| Assignee | ||
Comment 9•15 years ago
|
||
Attachment #497324 -
Attachment is obsolete: true
Attachment #499124 -
Flags: review?(karlt)
Attachment #497324 -
Flags: review?(karlt)
Updated•15 years ago
|
Attachment #499124 -
Flags: review?(karlt) → review+
| Assignee | ||
Updated•15 years ago
|
Keywords: checkin-needed
Whiteboard: [has patch][needs review karl] → [has patch]
| Assignee | ||
Comment 10•15 years ago
|
||
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Updated•15 years ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•