Open Bug 1022241 Opened 10 years ago Updated 1 year ago

search box dropdown can show up in the middle of nowhere

Categories

(Core :: Widget: Gtk, defect, P3)

x86_64
Linux
defect

Tracking

()

People

(Reporter: glandium, Unassigned)

References

(Blocks 3 open bugs, )

Details

(Whiteboard: tpi:+)

Attachments

(3 files)

Attached image Screenshot
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.
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.
Blocks: gtk3
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.
But that's the only form where I've had a dropdown misplaced on Gtk2 builds.
Can see this too. Gnome search box suggestion are shown on the bottom of the browser window. See attached screenshot.
i've also had this with the autocomplete on the url input.
(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
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).
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.
Does this only happen with certain window managers?
I'm running Gnome Shell on Ubuntu 14.04.
Assignee: nobody → edwin
Status: NEW → ASSIGNED
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)
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)
(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)
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?
Likely the same issue, thanks.
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.)
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.
Yes, I can reproduce that on Cinamon/Fedora 23. Will look at it.
Blocks: 1223020
From some unknown reason the widget position is reverted in nsWindow::NativeShow() when popup is hiding by gtk_widget_hide(GTK_WIDGET(mShell).
No longer blocks: 1223020
Attached file testcase
It's a GTK bug, there's a testcase for it.
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.
Flags: needinfo?(wmccloskey)
See Also: → 1239855
(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)
(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.
See Also: → 1167694
See Also: → 1269786
Blocks: 1283805
Blocks: 1286641
Blocks: 1289383
Priority: -- → P3
Whiteboard: tpi:+
Happens to me with Mint 17.3 and Cinnamon as well as Ubuntu 16.04 and xfce4, Firefox 49.0 .
(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.
still happens for me with firefox 50.1.0 with gtk3-3.22.5 under fedora 25
to clarify: it does not happen with searchbox/urlbox but with dropdowns in forms on the actual webpage
From time to time i get tooltips (from title= attributes) at the wrong position as well.
Happens with tooltips of browser tabs as well.
Possibly fixed in 51.0?

At least i didn't observe it for a while.
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.
(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.
Still happening with tooltips for me, but not with dropdowns.
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.
Bug 1443752 reported it happening in Firefox 58
Still happening in Firefox 62 (64bit) running on Ubuntu 18.

Still a thing in Firefox 66, Ubuntu 19.04. Not sure if this is a helpful comment

Severity: normal → S3

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)

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.