search box dropdown can show up in the middle of nowhere

NEW
Unassigned

Status

()

defect
P3
normal
5 years ago
18 days ago

People

(Reporter: glandium, Unassigned)

Tracking

(Blocks 3 bugs)

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: tpi:+, )

Attachments

(3 attachments)

Reporter

Description

5 years ago
Posted 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.
Reporter

Comment 1

5 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

Updated

5 years ago
Blocks: gtk3
Reporter

Comment 2

5 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

5 years ago
But that's the only form where I've had a dropdown misplaced on Gtk2 builds.

Comment 4

5 years ago
Can see this too. Gnome search box suggestion are shown on the bottom of the browser window. See attached screenshot.

Comment 6

5 years ago
i've also had this with the autocomplete on the url input.

Comment 7

4 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

4 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

4 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.
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

4 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)
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).

Updated

4 years ago
No longer blocks: 1223020
Posted 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
Duplicate of this bug: 1280226
Blocks: 1286641
Blocks: 1289383
Duplicate of this bug: 1283805
Priority: -- → P3
Whiteboard: tpi:+

Comment 33

3 years ago
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.

Comment 35

2 years ago
still happens for me with firefox 50.1.0 with gtk3-3.22.5 under fedora 25

Comment 36

2 years ago
to clarify: it does not happen with searchbox/urlbox but with dropdowns in forms on the actual webpage
Duplicate of this bug: 1328091
Duplicate of this bug: 1325589

Comment 39

2 years ago
From time to time i get tooltips (from title= attributes) at the wrong position as well.

Comment 40

2 years ago
Happens with tooltips of browser tabs as well.

Comment 41

2 years ago
Possibly fixed in 51.0?

At least i didn't observe it for a while.

Comment 42

2 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

2 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

2 years ago
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.
Duplicate of this bug: 1443752
Bug 1443752 reported it happening in Firefox 58

Comment 48

8 months ago
Still happening in Firefox 62 (64bit) running on Ubuntu 18.

Comment 49

18 days ago

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

You need to log in before you can comment on or make changes to this bug.