Bug 16450 – [GTK] hangs when big combobox opened

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKitGTK

[Jakub 'Livio' Rusinek]

webkit-based browser hangs when big combobox is opened.
eg. on http://bugzilla.redhat.com/ entries.

[Marco Barisione]

We could increase performances caching someway the menu items but most of the time is passed in gtk_menu_popup() so I don't know how webkit could fix this.

[Jakub 'Livio' Rusinek]

I can only say, that this works in Gecko.

[Marco Barisione]

Gecko (even in FF3) doesn't use a real gtk menu.
How many elements are there in the popup menu causing troubles?

[Jakub 'Livio' Rusinek]

5483 (from https://admin.fedoraproject.org/pkgdb/collections/ )

[Marco Barisione]

Created attachment 19902 [details]
Test program for GTK combo boxes

GTK+ is slow both creating and displaying the combo box popup menu.

Maybe the menu could be cached to avoid recreating it each time, but I don't know if it's simple to do and if it's so useful.

[Jakub 'Livio' Rusinek]

so, this is not a stereotype, that gtk isn't fast and kinda unusable :/ .

[Christian Dywan]

What is the status of this bug?

I cannot see a combobox on the example website. Please provide a real example that does not depend on a user account, assuming this is the reason I don't see it.

Generally if there seriously is a combobox that contains 5483 elements I don't consider it a problem on the gtk or webkit side, but in my opinion there is something wrong with the website. A (popup) menu is the wrong kind of interface for this.

[Jakub 'Livio' Rusinek]

> What is the status of this bug?

Probably still true.

> I cannot see a combobox on the example website. Please provide a real example
> that does not depend on a user account, assuming this is the reason I don't 
> see it.

If you don't have account there - that's not my problem. Bug exists and I'm reporting it - all my bussiness.

> Generally if there seriously is a combobox that contains 5483 elements I don't
> consider it a problem on the gtk or webkit side, but in my opinion there is
> something wrong with the website. A (popup) menu is the wrong kind of 
> interface for this.

That's not time and place for advices. That's not your bussiness what page incorporates - since it works well in other browsers, should work in WebKit-based too.

[Marco Barisione]

Created attachment 21715 [details]
Test case

[Gustavo Noronha (kov)]

This seems to be GTK+ bug 153605: http://bugzilla.gnome.org/show_bug.cgi?id=153605

[Yaakov Selkowitz]

I'm still seeing this with bugzilla.redhat.com entries; one CPU goes full throttle and memory use skyrockets until I have to kill Epiphany.  The GNOME bug (comment #9) indicates that this may be an issue with WebKitGtk's custom combobox implementation.  Could someone clarify?

[Michael Catanzaro]

*** Bug 146794 has been marked as a duplicate of this bug. ***

[Michael Catanzaro]

See bug #146794 for a backtrace taken during such a hang.

[Michael Catanzaro]

If we move Epiphany's new GtkTreeView-based select element implementation to WebKit next cycle, that would (presumably) avoid this bug.

[Adrian Perez]

(In reply to Michael Catanzaro from comment #14)
> If we move Epiphany's new GtkTreeView-based select element implementation to
> WebKit next cycle, that would (presumably) avoid this bug.

I think here “next cycle” meant targeting 2.20.x, but we did not manage
to import Epiphany's implementation. Let's try to do it during the current
cycle and target 2.22.x

[Adrian Perez]

(In reply to Adrian Perez from comment #15)
> (In reply to Michael Catanzaro from comment #14)
> > If we move Epiphany's new GtkTreeView-based select element implementation to
> > WebKit next cycle, that would (presumably) avoid this bug.
> 
> I think here “next cycle” meant targeting 2.20.x, but we did not manage
> to import Epiphany's implementation. Let's try to do it during the current
> cycle and target 2.22.x

It's happening, see bug #186146 \o/

[Adrian Perez]

(In reply to Adrian Perez from comment #16)
> (In reply to Adrian Perez from comment #15)
> > (In reply to Michael Catanzaro from comment #14)
> > > If we move Epiphany's new GtkTreeView-based select element implementation to
> > > WebKit next cycle, that would (presumably) avoid this bug.
> > 
> > I think here “next cycle” meant targeting 2.20.x, but we did not manage
> > to import Epiphany's implementation. Let's try to do it during the current
> > cycle and target 2.22.x
> 
> It's happening, see bug #186146 \o/

The new implementation has been in WebKitGTK+ 2.20.x for a good while,
and opening e.g. the popup in the linked test code is almost immediate.
It does still take some (noticeable) milliseconds for the popup to
appear, but it's under half a second here, but the CPU is not hogged
anymore.

Let's close this, but if you find any other situation in which this is
still a problem, do not hesitate in reopening :-)

[Bastien Nocera]

(In reply to Adrian Perez from comment #17)
> The new implementation has been in WebKitGTK+ 2.20.x for a good while,
> and opening e.g. the popup in the linked test code is almost immediate.
> It does still take some (noticeable) milliseconds for the popup to
> appear, but it's under half a second here, but the CPU is not hogged
> anymore.
> 
> Let's close this, but if you find any other situation in which this is
> still a problem, do not hesitate in reopening :-)

Do you have a test site to be used? The Buzgilla links that were here and in bug 186146 have changed so that the bug can't be reproduced on those anymore.

[Michael Catanzaro]

I

[Michael Catanzaro]

Sorry, I'm not aware of any good test sites for this now that Red Hat Bugzilla changed, but we have a completely different implementation for select elements now, so it's quite unlikely that this would still be an issue.

[Adrian Perez]

(In reply to Bastien Nocera from comment #18)
> (In reply to Adrian Perez from comment #17)
> > The new implementation has been in WebKitGTK+ 2.20.x for a good while,
> > and opening e.g. the popup in the linked test code is almost immediate.
> > It does still take some (noticeable) milliseconds for the popup to
> > appear, but it's under half a second here, but the CPU is not hogged
> > anymore.
> > 
> > Let's close this, but if you find any other situation in which this is
> > still a problem, do not hesitate in reopening :-)
> 
> Do you have a test site to be used? The Buzgilla links that were here and in
> bug 186146 have changed so that the bug can't be reproduced on those anymore.

You can try with the HTML file attached to this bug. It used to cause
WebKitGTK+ to hang for many seconds while trying to open the popup,
and works fine now.

[Bastien Nocera]

(In reply to Adrian Perez from comment #21)
> You can try with the HTML file attached to this bug. It used to cause
> WebKitGTK+ to hang for many seconds while trying to open the popup,
> and works fine now.

Sorry, completely missed the test case. In which version of WebKitGTK+ was the new implementation added? Using the MiniBrowser shipped with webkit2gtk3-2.20.3-1.fc28.x86_64, I can still see the problem with the drop-down taking a long time, and epiphany's version works fine (bar another problem with the scrolling).

[Michael Catanzaro]

(In reply to Bastien Nocera from comment #22)
> Sorry, completely missed the test case. In which version of WebKitGTK+ was
> the new implementation added?

It's new in 2.22, so the behavior you notice is expected