Bug 77210
| Summary: | [Qt] Loading yahoo.com lock the UIProcess. | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Alexis Menard (darktears) <menard> |
| Component: | WebKit Qt | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | Major | CC: | allan.jensen, hausmann, jturcotte, kenneth, noam |
| Priority: | P1 | Keywords: | Qt, QtTriaged |
| Version: | 528+ (Nightly build) | ||
| Hardware: | PC | ||
| OS: | Linux | ||
Alexis Menard (darktears)
Hi,
If you try and compile https://github.com/snowshoe/snowshoe , loading a page like yahoo, google or planetkde.org will be slow. Around the end of the loading the UIProcess get stuck and you can't even click on the UI. It kills a bit the concept of responsiveness of WK2. Snowshoe is using the desktop mode (which we need to have in correct shape as it runs our layout tests). I profiled quickly, it seemed related to re-sizing the drawing area too much or incorrectly. Also I feel very surprised that the loading doesn't look progressive (text, then image, ...) like Chrome or Safari. It loads, let the page blank and when everything is there (after being stuck) it display the entire page.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Alexis Menard (darktears)
After updating to a recent version it seems that it works much better. Still yahoo.com stuck the UIProcess at the end of the load.
Alexis Menard (darktears)
(In reply to comment #1)
> After updating to a recent version it seems that it works much better. Still yahoo.com stuck the UIProcess at the end of the load.
Most probably related to plugins.
Allan Sandfeld Jensen
As far I as debugged it earlier, what happens is that the first initialization of the plugin process uses a blocking call with no timeout, and this is where we get stuck.
I think the problem might be resolved if we implement restarting crashed processes.
Allan Sandfeld Jensen
Please retest to see if this bug still apply after bug #93272 has been fixed.
Allan Sandfeld Jensen
With no feedback and unable to reproduce the issue myself, I am going to assume this has been fixed in another bug.