Open
Bug 1022241
Opened 11 years ago
Updated 3 months ago
search box dropdown can show up in the middle of nowhere
Categories
(Core :: Widget: Gtk, defect, P3)
Tracking
()
NEW
People
(Reporter: glandium, Unassigned)
References
(Blocks 3 open bugs, )
Details
(Whiteboard: tpi:+)
Attachments
(3 files)
This may of may not be Gtk3 specific. I've never seen that happen on Gtk2, but I was also using 31 Gtk2 builds while this one is a 32 Gtk3 build.
The search box dropdown, instead of being right below the search box, can appear in the middle of nowhere. See attached screenshot, where it's roughly at the vertical middle of the window.
It is somehow tab-dependent. Like, when it happens, if I open a new tab, it doesn't happen there. Then if I go back to an existing tab, it does happen. But then, if I return to the newly created tab, it happens there too.
Reporter | ||
Comment 1•11 years ago
|
||
In fact, this also happens on dropdowns on content input fields when they have completion. Interestingly, for those, they can show up at the location the search box dropdown should have.
Reporter | ||
Comment 2•10 years ago
|
||
Something I forgot to mention that is very interesting: on mcMerge (https://tbpl.mozilla.org/mcmerge/), the dropdown for the autofill for the user name is shown at the right place the first time, while it's *never* at the right place on Gtk2 builds.
Reporter | ||
Comment 3•10 years ago
|
||
But that's the only form where I've had a dropdown misplaced on Gtk2 builds.
Comment 4•10 years ago
|
||
Can see this too. Gnome search box suggestion are shown on the bottom of the browser window. See attached screenshot.
Comment 5•10 years ago
|
||
Comment 6•10 years ago
|
||
i've also had this with the autocomplete on the url input.
Comment 7•10 years ago
|
||
(In reply to Johnny Robeson from comment #6)
> i've also had this with the autocomplete on the url input.
I can no longer reproduce this issue in the GTK3 enabled Firefox (38.0-5) packaged for Fedora 22
Comment 8•9 years ago
|
||
I was able to replicate this yesterday, but I don't see it again today (with the same firefox version as in my previous comment).
Comment 9•9 years ago
|
||
I think my problem was a side effect of this bug https://bugzilla.mozilla.org/show_bug.cgi?id=1160154 and not the actual problem in this ticket.
Just want to point out that bug 1193532 has reproducible STR this bug. I bisected it to the GTK3 on-by-default patch.
Comment 12•9 years ago
|
||
Does this only happen with certain window managers?
I'm running Gnome Shell on Ubuntu 14.04.
Assignee: nobody → edwin
Status: NEW → ASSIGNED
Reporter | ||
Comment 14•9 years ago
|
||
I am using Gnome Shell too. Note that I haven't seen this happen in a long while, though, and I can't reproduce with the STR from bug 1193532. Bill, what about you? (that may well have been a Gnome Shell bug or a combination of bad hints on our part with some Gnome Shell bug)
Hm. I was able to reproduce this just once, but can't anymore. Tried a few different machines.
Unassigning in case somebody who can repro wants to debug it.
Assignee: edwin → nobody
Status: ASSIGNED → NEW
Flags: needinfo?(wmccloskey)
Comment 16•9 years ago
|
||
If someone can catch this in an rr session that would help a lot in being able to make progress
I can still reproduce the STR in bug 1193532.
I've never shared an rr trace with someone. Do you need ssh access to my machine, or can I just send you the file?
Flags: needinfo?(wmccloskey)
Comment 18•9 years ago
|
||
(In reply to Bill McCloskey (:billm) from comment #17)
> I can still reproduce the STR in bug 1193532.
>
> I've never shared an rr trace with someone. Do you need ssh access to my
> machine, or can I just send you the file?
Sharing the rr trace probably won't work. If you're comfortable with giving ssh access that would be great otherwise we can try to do a guided debugging session.
Flags: needinfo?(wmccloskey)
Comment 19•9 years ago
|
||
I've seen this happen using xfwm4 (running MATE) and mutter (running Cinnamon).
I also see this happening with context/pop-up sub-menus. Is this likely the same issue, or should I file another bug?
Comment 20•9 years ago
|
||
Likely the same issue, thanks.
Comment 21•9 years ago
|
||
I get this issue with the awsomebar dropdown, panels like the application menu, and the right click context menu. I'm using Linux Mint/Cinnamon. Here's STR for the context menu position problem:
1. Open a new window.
2. Right click somewhere in content to open the context menu.
3. Without moving the mouse, right click again to close the context menu.
4. Move the window.
5. Right click somewhere in content to open the context menu.
6. Without moving the mouse, right click again to close the context menu.
The popup opened in step 6 will be in the wrong position. (Steps 3 and 5 don't need to use the mouse to close the popup; pressing Escape works too.)
Comment 22•9 years ago
|
||
There seems to be some issue managing the origin of these popups. The first time the origin changes, the popup is positioned correctly. But if the origin is changed and reused, then things get wonky.
Alternate context menu STR:
1. Open a new window.
2. Open a content context menu.
3. Dismiss the context menu.
4. Open a content context menu in a different location.
5. Dismiss the context menu without moving the mouse.
6. Open a content context menu in the same location #4.
Expected Results:
The context menu opened in #6 will be anchored to the mouse pointer.
Actual results:
The context menu opened in #6 (and subsequent repeats of steps #4 - #6) will be anchored to the original location of the first content menu opened in #2.
Location bar STR:
1. Open a new window.
2. Open the location bar drop down.
3. Dismiss the location bar drop down.
4. Move the window.
5. Open the location bar drop down.
6. Dismiss the location bar drop down.
7. Open the location bar drop down.
Expected Results:
The drop down opened in #7 will be anchored to the location bar input box.
Actual results:
The drop down opened in #7 (and subsequent repeats of steps #4 - #7) will be anchored to the original location from #2.
Comment 23•9 years ago
|
||
Yes, I can reproduce that on Cinamon/Fedora 23. Will look at it.
Comment 24•9 years ago
|
||
From some unknown reason the widget position is reverted in nsWindow::NativeShow() when popup is hiding by gtk_widget_hide(GTK_WIDGET(mShell).
Comment 25•9 years ago
|
||
It's a GTK bug, there's a testcase for it.
Comment 26•9 years ago
|
||
A workaround here is to explicitly move the popup window before show. The problem is that some DE (Cinamon) sends expose_event to hidden popup window which predates Gtk internal logic.
Updated•9 years ago
|
Flags: needinfo?(wmccloskey)
Comment 27•9 years ago
|
||
Comment 28•9 years ago
|
||
(In reply to Martin Stránský from comment #26)
> A workaround here is to explicitly move the popup window before show. The
> problem is that some DE (Cinamon) sends expose_event to hidden popup window
> which predates Gtk internal logic.
Could you detail more about what this workaround would entail?
Flags: needinfo?(stransky)
Comment 29•9 years ago
|
||
(In reply to Lee Salzman [:lsalzman] from comment #28)
> (In reply to Martin Stránský from comment #26)
> > A workaround here is to explicitly move the popup window before show. The
> > problem is that some DE (Cinamon) sends expose_event to hidden popup window
> > which predates Gtk internal logic.
>
> Could you detail more about what this workaround would entail?
AFAIK It may be something in sView::CalcWidgetBounds() where widget coordinates are compared and the stored coordinates are incorrect due to this bug.
The move/resize logic si here:
http://mxr.mozilla.org/mozilla-central/source/view/nsView.cpp#367
It may involve to invalidate the stored coordinates and always move position of the restored widget. But I have very little knowledge about layout code so better to ask someone from layout team.
Flags: needinfo?(stransky)
Without reading all the comments, I see this problem on OS X.
Updated•8 years ago
|
Priority: -- → P3
Whiteboard: tpi:+
Comment 33•8 years ago
|
||
Happens to me with Mint 17.3 and Cinnamon as well as Ubuntu 16.04 and xfce4, Firefox 49.0 .
Comment 34•8 years ago
|
||
(In reply to Martin Stránský from comment #25)
> Created attachment 8687161 [details]
> testcase
>
> It's a GTK bug, there's a testcase for it.
(In reply to Olivier Fourdan from comment #27)
> Sounds like https://bugzilla.gnome.org/show_bug.cgi?id=758609
This Gtk+ bug is supposedly fixed in 3.19.4, but the bug is still present in Firefox 50.
Comment 35•8 years ago
|
||
still happens for me with firefox 50.1.0 with gtk3-3.22.5 under fedora 25
Comment 36•8 years ago
|
||
to clarify: it does not happen with searchbox/urlbox but with dropdowns in forms on the actual webpage
Comment 39•8 years ago
|
||
From time to time i get tooltips (from title= attributes) at the wrong position as well.
Comment 40•8 years ago
|
||
Happens with tooltips of browser tabs as well.
Updated•8 years ago
|
Blocks: gtk3-pre-3.20
Comment 41•8 years ago
|
||
Possibly fixed in 51.0?
At least i didn't observe it for a while.
Comment 42•8 years ago
|
||
It's not fixed in 51; I see it in 52. I have libgtk-3 3.10.8 installed, which is older than the 3.19.x in which the gtk3 bug was supposedly introduced. I am using Cinnamon just as mentioned in comment 33. I have two monitors; sometimes the dropdown shows up in the wrong place on the same monitor as the browser window, while other times the dropdown shows up on the other monitor altogether!
Moving the browser window even slightly causes the dropdown to show up in the right location the next time it is shown. Subsequent draws of the dropdown show up in the wrong location.
Restarting the browser seems to "fix" the issue for a while, but it always eventually returns.
Comment 43•8 years ago
|
||
(In reply to josef radinger from comment #36)
> to clarify: it does not happen with searchbox/urlbox but with dropdowns in
> forms on the actual webpage
It happens to me with the searchbox / awesome bar dropdown. It _may_ happen with forms as well, but I don't notice it as much.
It's possible there are two separate bugs (one with forms and one with the awesome bar), but I'm assuming someone thinks they are the same bug, since bug 1289383 (which this bug blocks) is specifically for the awesome bar.
Comment 44•8 years ago
|
||
Still happening with tooltips for me, but not with dropdowns.
Comment 45•7 years ago
|
||
I recently got ESR 52 from Debian jessie security and am getting misplaced form autocomplete dropdowns, with libgtk-3-0:amd64 3.14.5-1+deb8u1.
Comment 47•7 years ago
|
||
Bug 1443752 reported it happening in Firefox 58
Comment 48•6 years ago
|
||
Still happening in Firefox 62 (64bit) running on Ubuntu 18.
Comment 49•6 years ago
|
||
Still a thing in Firefox 66, Ubuntu 19.04. Not sure if this is a helpful comment
Updated•2 years ago
|
Severity: normal → S3
Comment 50•2 years ago
|
||
The severity field for this bug is relatively low, S3. However, the bug has 6 duplicates and 10 votes.
:stransky, could you consider increasing the bug severity?
For more information, please visit auto_nag documentation.
Flags: needinfo?(stransky)
Comment 51•2 years ago
|
||
The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.
Flags: needinfo?(stransky)
You need to log in
before you can comment on or make changes to this bug.
Description
•