Bug 59017 - [GTK] Implement History API FrameLoaderClient methods
Summary: [GTK] Implement History API FrameLoaderClient methods
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC OS X 10.5
: P2 Normal
Assignee: Xan Lopez
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-04-20 12:37 PDT by Xan Lopez
Modified: 2011-12-03 12:06 PST (History)
5 users (show)

See Also:


Attachments
history.diff (4.71 KB, patch)
2011-04-20 12:38 PDT, Xan Lopez
no flags Details | Formatted Diff | Diff
history.diff (4.71 KB, patch)
2011-04-20 13:05 PDT, Xan Lopez
no flags Details | Formatted Diff | Diff
Patch (4.00 KB, patch)
2011-12-03 06:31 PST, Xan Lopez
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Xan Lopez 2011-04-20 12:37:02 PDT
We need to fake a load when they are used for our UA to have a chance of updating its state in the UI. This makes pages like http://diveintohtml5.org/examples/history/casey.html work in Epiphany.
Comment 1 Xan Lopez 2011-04-20 12:38:25 PDT
Created attachment 90386 [details]
history.diff
Comment 2 WebKit Review Bot 2011-04-20 12:47:10 PDT
Attachment 90386 [details] did not pass style-queue:

Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files', u'Source/WebKit/gtk/ChangeLog', u'Source/Web..." exit_code: 1

Source/WebKit/gtk/WebCoreSupport/FrameLoaderClientGtk.cpp:908:  Declaration has space between type name and * in WebKitWebFrame *mainFrame  [whitespace/declaration] [3]
Source/WebKit/gtk/WebCoreSupport/FrameLoaderClientGtk.cpp:909:  Declaration has space between type name and * in WebKitWebDataSource *dataSource  [whitespace/declaration] [3]
Total errors found: 2 in 3 files


If any of these errors are false positives, please file a bug against check-webkit-style.
Comment 3 Xan Lopez 2011-04-20 13:05:38 PDT
Created attachment 90392 [details]
history.diff

Nothing to see here, move along.
Comment 4 Martin Robinson 2011-04-20 13:09:29 PDT
View in context: https://bugs.webkit.org/attachment.cgi?id=90386&action=review

Seems okay, but please consider my comments below when landing.

> Source/WebKit/gtk/WebCoreSupport/FrameLoaderClientGtk.cpp:913
> +    WebKitWebView* webView = getViewFromFrame(m_frame);
> +    WebKitWebFrame *mainFrame = webView->priv->mainFrame;
> +    WebKitWebDataSource *dataSource = webkit_web_frame_get_data_source(mainFrame);
> +    bool loaderCompleted = !webkit_web_data_source_is_loading(dataSource);
> +
> +    if (!loaderCompleted)
> +        return;

This can all be reduced to two lines with something like:

if (core(getViewFromFrame(m_frame))->mainFrame()->loader()->activeDocumentLoader()->isLoadingInAPISense())
    return;

I would also leave a comment explaining why you don't want to send these signals during loading.
Comment 5 Martin Robinson 2011-04-20 13:09:49 PDT
Comment on attachment 90392 [details]
history.diff

r+ with changes above.
Comment 6 Xan Lopez 2011-04-20 21:07:09 PDT
Dumping here some comments Martin and I had about this on jabber:

- If we commit the patch as-is we break at least one invariant our code had before: we'll emit a provisional load signal without having a provisional data source/request. In theory this cannot happen.

- If we skip the provisional stage this to avoid the former, we break another invariant: we go through committed and finished before having started at provisional. I believe this, also, cannot happen in theory.

So I'm having second thoughts about this. If I had to choose I'd probably decide to go for option a). CCing Gustavo in case he wants to comment.
Comment 7 Gustavo Noronha (kov) 2011-05-09 18:28:39 PDT
(In reply to comment #6)
> Dumping here some comments Martin and I had about this on jabber:
> 
> - If we commit the patch as-is we break at least one invariant our code had before: we'll emit a provisional load signal without having a provisional data source/request. In theory this cannot happen.
> 
> - If we skip the provisional stage this to avoid the former, we break another invariant: we go through committed and finished before having started at provisional. I believe this, also, cannot happen in theory.
> 
> So I'm having second thoughts about this. If I had to choose I'd probably decide to go for option a). CCing Gustavo in case he wants to comment.

We can create a fake provisional data source/request, perhaps? Even if we don't, I think the first option is the one with less chance of causing breakage, so I'd go with it.
Comment 8 Eric Seidel (no email) 2011-06-18 13:43:14 PDT
Attachment 90392 [details] was posted by a committer and has review+, assigning to Xan Lopez for commit.
Comment 9 Xan Lopez 2011-12-03 06:31:45 PST
Created attachment 117756 [details]
Patch
Comment 10 WebKit Review Bot 2011-12-03 12:06:26 PST
Comment on attachment 117756 [details]
Patch

Clearing flags on attachment: 117756

Committed r101933: <http://trac.webkit.org/changeset/101933>
Comment 11 WebKit Review Bot 2011-12-03 12:06:31 PST
All reviewed patches have been landed.  Closing bug.