Bug 16450 - [GTK] hangs when big combobox opened
Summary: [GTK] hangs when big combobox opened
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Linux
: P2 Normal
Assignee: Nobody
URL:
Keywords:
: 146794 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-12-15 05:56 PST by Jakub 'Livio' Rusinek
Modified: 2018-08-08 14:12 PDT (History)
10 users (show)

See Also:


Attachments
Test program for GTK combo boxes (962 bytes, text/plain)
2008-03-20 12:15 PDT, Marco Barisione
no flags Details
Test case (204.06 KB, text/html)
2008-06-15 11:28 PDT, Marco Barisione
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jakub 'Livio' Rusinek 2007-12-15 05:56:40 PST
webkit-based browser hangs when big combobox is opened.
eg. on http://bugzilla.redhat.com/ entries.
Comment 1 Marco Barisione 2008-03-14 05:49:25 PDT
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.
Comment 2 Jakub 'Livio' Rusinek 2008-03-14 06:15:25 PDT
I can only say, that this works in Gecko.
Comment 3 Marco Barisione 2008-03-19 06:34:19 PDT
Gecko (even in FF3) doesn't use a real gtk menu.
How many elements are there in the popup menu causing troubles?
Comment 4 Jakub 'Livio' Rusinek 2008-03-19 10:28:54 PDT
5483 (from https://admin.fedoraproject.org/pkgdb/collections/ )
Comment 5 Marco Barisione 2008-03-20 12:15:20 PDT
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.
Comment 6 Jakub 'Livio' Rusinek 2008-03-20 13:55:38 PDT
so, this is not a stereotype, that gtk isn't fast and kinda unusable :/ .
Comment 7 Christian Dywan 2008-06-15 09:29:11 PDT
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.
Comment 8 Jakub 'Livio' Rusinek 2008-06-15 11:11:13 PDT
> 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.
Comment 9 Marco Barisione 2008-06-15 11:28:05 PDT
Created attachment 21715 [details]
Test case
Comment 10 Gustavo Noronha (kov) 2009-03-23 07:08:23 PDT
This seems to be GTK+ bug 153605: http://bugzilla.gnome.org/show_bug.cgi?id=153605
Comment 11 Yaakov Selkowitz 2014-07-18 11:51:31 PDT
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?
Comment 12 Michael Catanzaro 2015-07-09 13:54:46 PDT
*** Bug 146794 has been marked as a duplicate of this bug. ***
Comment 13 Michael Catanzaro 2015-07-09 13:56:03 PDT
See bug #146794 for a backtrace taken during such a hang.
Comment 14 Michael Catanzaro 2017-08-15 14:50:02 PDT
If we move Epiphany's new GtkTreeView-based select element implementation to WebKit next cycle, that would (presumably) avoid this bug.
Comment 15 Adrian Perez 2018-05-02 16:46:33 PDT
(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
Comment 16 Adrian Perez 2018-05-31 06:21:01 PDT
(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/
Comment 17 Adrian Perez 2018-08-06 08:51:22 PDT
(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 :-)
Comment 18 Bastien Nocera 2018-08-08 08:16:58 PDT
(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.
Comment 19 Michael Catanzaro 2018-08-08 09:03:18 PDT
I
Comment 20 Michael Catanzaro 2018-08-08 09:04:23 PDT
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.
Comment 21 Adrian Perez 2018-08-08 12:48:49 PDT
(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.
Comment 22 Bastien Nocera 2018-08-08 13:42:08 PDT
(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).
Comment 23 Michael Catanzaro 2018-08-08 14:12:00 PDT
(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