| Summary: | [GTK] hangs when big combobox opened | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Jakub 'Livio' Rusinek <jakub.rusinek> | ||||||
| Component: | WebKitGTK | Assignee: | Nobody <webkit-unassigned> | ||||||
| Status: | RESOLVED FIXED | ||||||||
| Severity: | Normal | CC: | alp, aperez, berto, bugs-noreply, bugzilla, cgarcia, marco.barisione, mcatanzaro, yselkowi, zan | ||||||
| Priority: | P2 | ||||||||
| Version: | 528+ (Nightly build) | ||||||||
| Hardware: | PC | ||||||||
| OS: | Linux | ||||||||
| See Also: |
https://bugzilla.gnome.org/show_bug.cgi?id=153605 https://bugs.webkit.org/show_bug.cgi?id=186146 |
||||||||
| Attachments: |
|
||||||||
|
Description
Jakub 'Livio' Rusinek
2007-12-15 05:56:40 PST
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. I can only say, that this works in Gecko. Gecko (even in FF3) doesn't use a real gtk menu. How many elements are there in the popup menu causing troubles? 5483 (from https://admin.fedoraproject.org/pkgdb/collections/ ) 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.
so, this is not a stereotype, that gtk isn't fast and kinda unusable :/ . 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. > 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. Created attachment 21715 [details]
Test case
This seems to be GTK+ bug 153605: http://bugzilla.gnome.org/show_bug.cgi?id=153605 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? *** Bug 146794 has been marked as a duplicate of this bug. *** See bug #146794 for a backtrace taken during such a hang. If we move Epiphany's new GtkTreeView-based select element implementation to WebKit next cycle, that would (presumably) avoid this bug. (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 (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/ (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 :-) (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. I 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. (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. (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). (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 |