After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 695733 - [WK2] Load gets stuck going back to the overview
[WK2] Load gets stuck going back to the overview
Status: RESOLVED OBSOLETE
Product: epiphany
Classification: Core
Component: General
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Epiphany Maintainers
Epiphany Maintainers
Depends on:
Blocks: 678610
 
 
Reported: 2013-03-12 22:18 UTC by Xan Lopez
Modified: 2013-05-21 09:48 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch (2.60 KB, patch)
2013-03-18 09:20 UTC, Manuel Rego Casasnovas
none Details | Review
Patch (1.48 KB, patch)
2013-04-12 10:07 UTC, Manuel Rego Casasnovas
none Details | Review

Description Xan Lopez 2013-03-12 22:18:25 UTC
Steps:

- Open new tab
- Go to google.com
- Press back button
- Load gets stuck forever (although the overview is loaded), URI entry is not modified
Comment 1 Manuel Rego Casasnovas 2013-03-13 18:19:44 UTC
(In reply to comment #0)
> - Load gets stuck forever (although the overview is loaded), URI entry is not
> modified

Just to complete the information, page title is not modified either.
Comment 2 Manuel Rego Casasnovas 2013-03-13 22:30:35 UTC
I've been taking a look to this problem and it reminds me to bug #695437 (maybe they're duplicated).

When you click the back button, method load_changed_cb() of ephy-embed.c is only called once with status WEBKIT_LOAD_STARTED. However, it's not called anymore with status WEBKIT_LOAD_COMMITTED or WEBKIT_LOAD_FINISHED. It even doesn't fail if you connect to the "load-failed" signal.

The overview is loaded because of in WK2 we only wait for WEBKIT_LOAD_STARTED (instead of WEBKIT_LOAD_COMMITTED, like in WK1) in order to call ephy_embed_set_overview_mode().
Comment 3 Manuel Rego Casasnovas 2013-03-15 08:49:57 UTC
This also happens with normal URIs, not only about: ones. It seems a WebKit bug as I've been able to reproduce it in the Minibrowser as explained here: https://bugs.webkit.org/show_bug.cgi?id=112418

Let's see if once the WebKit bug is fixed the issue and the one described in bug #695437 disappear.
Comment 4 Manuel Rego Casasnovas 2013-03-18 09:20:37 UTC
Created attachment 239103 [details] [review]
Patch


With the patch attached to http://webkit.org/b/112418 the issue disappears.

Anyway, I'm attaching a patch that could be applied after the WebKit bug lands, in order to share the same code in WK1 and WK2 to set the overview mode as now WEBKIT_LOAD_COMMITTED is properly emitted and there's no reason to have different code here.
Comment 5 Manuel Rego Casasnovas 2013-04-12 10:07:34 UTC
Created attachment 241334 [details] [review]
Patch

The WebKit bug (http://webkit.org/b/112418) has been fixed and it has been already applied in the stable branch.

I'm attaching and uploaded file as the code for WK1 has been already removed, but I think it would be better to keep the code like it was in WK1 waiting till the load is committed.

Anyway the issue described in this bug is fixed, so feel free to ignore my patch and close it.
Comment 6 Claudio Saavedra 2013-05-21 09:48:51 UTC
I think Ephy feels more responsive if we leave the overview already in STARTED. Waiting for committed means a couple of seconds in the overview after clicking on a thumbnail, and that feels slowish.

As per the correctness of the code, while it's true that in STARTED a URI can still change, I think it's not really an issue when we're talking about distinguishing between an about: and a non-about: uri. That is not going to change in committed.

So I think we can safely close this.