Bug 25867 - [QT] Implement original_url getter method to the API
: [QT] Implement original_url getter method to the API
Status: RESOLVED FIXED
: WebKit
WebKit Qt
: 528+ (Nightly build)
: PC All
: P2 Normal
Assigned To:
:
:
: 27444
:
  Show dependency treegraph
 
Reported: 2009-05-19 10:29 PST by
Modified: 2009-07-29 08:21 PST (History)


Attachments
patch 0.1 - implement originalUrl support (2.65 KB, patch)
2009-07-06 11:21 PST, Antonio Gomes
no flags Review Patch | Details | Formatted Diff | Diff
patch 0.2 - implement originalUrl support (2.69 KB, patch)
2009-07-06 12:51 PST, Antonio Gomes
hausmann: review-
Review Patch | Details | Formatted Diff | Diff
patch 0.2 - implement originalUrl support (6.65 KB, patch)
2009-07-16 12:55 PST, Antonio Gomes
no flags Review Patch | Details | Formatted Diff | Diff
patch 0.3 - implement originalUrl support (6.70 KB, patch)
2009-07-17 11:06 PST, Antonio Gomes
no flags Review Patch | Details | Formatted Diff | Diff
patch 0.4 - implement originalUrl support (7.56 KB, patch)
2009-07-20 08:08 PST, Antonio Gomes
no flags Review Patch | Details | Formatted Diff | Diff
patch 0.5 - implement originalUrl support (7.64 KB, patch)
2009-07-23 13:23 PST, Antonio Gomes
no flags Review Patch | Details | Formatted Diff | Diff
patch 0.6 - implement originalUrl support (8.53 KB, patch)
2009-07-24 05:52 PST, Antonio Gomes
hausmann: review+
Review Patch | Details | Formatted Diff | Diff


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2009-05-19 10:29:31 PST
In some cases (e.g. sites that redirects) the application may be interested in the original URL entered by the user, not only in the resolved one.

We should consider including support for that in our API, if convenient.
------- Comment #1 From 2009-05-19 10:32:01 PST -------
Please name it originalUrl() and let it return a QUrl. What to do it they user gives an invalid URL? what will originalUrl return? a nulled QUrl?
------- Comment #2 From 2009-06-03 06:09:30 PST -------
(In reply to comment #1)
> What to do it they user gives an invalid URL? what will originalUrl return? a nulled QUrl?

it will return an empty qurl, not null.
------- Comment #3 From 2009-06-03 06:09:59 PST -------
TESTCASE:

In practical terms, I am calling "original url" here the url fixed but not yet resolved
loaded by the current main frame, e.g. :

1) if user runs: $ ./QtLauncher google.com
2) it gets "fixed" to "http://google.com/"
3) it gets "resolved" to "http://www.google.com"
4) sometimes it also gets "redirected" to other pages , e.g.
"http://www.google.com.br"

--> originalUrl() would return 2).
--> url() would return either 3) or 4).

SCENARIO:

The motivation for this simple add comes from a feature we needed to implement a while back while working on a frontend for our webkit-efl port [1], and we thought that it could also be useful for other ports.

[1] http://code.staikos.net/cgi-bin/gitweb.cgi?p=webkit;a=shortlog;h=shared/webkit-efl

In our case we had the following scenario:

1) we have a history management implemented in ui side.
2) during the mainFrame's loading process, it firstly calls |WebCoreSupport::updateGlobalHistory()| passing the URL being loaded(see quoted code below). It is the url not resolved or redirected yet.

(...)
void FrameLoaderClientQt::updateGlobalHistory()
{
   QWebHistoryInterface *history = QWebHistoryInterface::defaultInterface();
   if (history)
       history->addHistoryEntry(m_frame->loader()->documentLoader()->urlForHistory().prettyURL());
}
(...)

We stored the url passed in in our history database as a primary key.

3) yet in the loading process, server responses to the loading process and we get urlChanged and titleChanged signals emited. In our case, we want to update the history database entry of the just obtained |title| for the web page. At that time (when titleChanged signal gets emited) we get the original url by calling mainFrame->originalUrl(), find the history entry in the database
associated to it and update it w/ the new title value.
------- Comment #4 From 2009-07-06 11:21:29 PST -------
Created an attachment (id=32309) [details]
patch 0.1 - implement originalUrl support

ps: I have not figure out a good way to add tests to this. any input welcome.
------- Comment #5 From 2009-07-06 12:51:41 PST -------
Created an attachment (id=32310) [details]
patch 0.2 - implement originalUrl support

updated to ToT
------- Comment #6 From 2009-07-14 07:16:55 PST -------
(From update of attachment 32310 [details])
Clearing from the review queue as per comment from IRC:
<tonikitoo> manyoso, tronical i am finishing originalURl patch ... adding a better test (as suggested by fawek) and better docs, as per simon's suggestion ...
------- Comment #7 From 2009-07-16 12:55:58 PST -------
Created an attachment (id=32888) [details]
patch 0.2 - implement originalUrl support

Test added: it creates a proper FakeNetworkAccessManager (:QNetworkAccessManager) and FakeReply (:QNetworkReply) in order to a redirect.
------- Comment #8 From 2009-07-16 12:59:18 PST -------
(From update of attachment 32888 [details])
see patch 0.3 also in

http://code.staikos.net/cgi-bin/gitweb.cgi?p=webkit;a=commitdiff;h=7aa68b24bcf949b3f78c25008e48a5de44d074b6
------- Comment #9 From 2009-07-16 16:13:52 PST -------
(From update of attachment 32888 [details])
cleanring review flag ... improvements to come !
------- Comment #10 From 2009-07-17 11:06:24 PST -------
Created an attachment (id=32958) [details]
patch 0.3 - implement originalUrl support

WIP: cleaned up
------- Comment #11 From 2009-07-20 08:08:23 PST -------
Created an attachment (id=33085) [details]
patch 0.4 - implement originalUrl support
------- Comment #12 From 2009-07-20 08:09:40 PST -------
patch is ready for review, but can not land before patch in bug 27444.

setting it as a dep.
------- Comment #13 From 2009-07-23 13:23:54 PST -------
Created an attachment (id=33361) [details]
patch 0.5 - implement originalUrl support

ready for review.
------- Comment #14 From 2009-07-23 14:12:39 PST -------
(From update of attachment 33361 [details])
clearing review again. got comments from itc
------- Comment #15 From 2009-07-24 05:52:38 PST -------
Created an attachment (id=33432) [details]
patch 0.6 - implement originalUrl support

1) ran style code script
2) left name as originalURL to match w/ QWebHistory::originalURL (as w/ gtk API )
3) updated to ToT
4) adde class doc overview
------- Comment #16 From 2009-07-24 07:04:55 PST -------
branch where to find the neswest patch (easier cherry pick)

http://code.staikos.net/cgi-bin/gitweb.cgi?p=webkit;a=shortlog;h=antonio/original-url
------- Comment #17 From 2009-07-24 08:14:58 PST -------
(From update of attachment 33432 [details])
r=me

Please submit a separate patch for the function renaming, as discussed on IRC :)
------- Comment #18 From 2009-07-24 11:22:29 PST -------
fixed

thanks simon, adam and kenneth. 

(In reply to comment #17)
> (From update of attachment 33432 [details] [details])
> r=me

landed in r46364

> Please submit a separate patch for the function renaming, as discussed on IRC
> :)

landed in r46367 (r=Adam Treat on irc)
------- Comment #19 From 2009-07-27 14:49:48 PST -------
Why the check for d->frameLoaderClient->m_loadSucceeded when deciding which url to return?

This check happens to break my use-case of this feature, which is to handle SSL failures that occur as the result of redirects (e.g. https://hotmail.com). When the failure occurs m_loadSucceeded is not yet true, and won't be until the ssl failure is accepted by the user.
------- Comment #20 From 2009-07-28 12:15:59 PST -------
(In reply to comment #19)
> Why the check for d->frameLoaderClient->m_loadSucceeded when deciding which url
> to return?

mwenge, when the load is not successful (e.g. user loads an non-existent url) the d->loader()->activeDocumentLoader stays referring the latest successful load (not to the latest failing one). so we could not query the originalUrl off of it.

please see details in bug 27444 .

given that, I used this m_loadSucceeded flag to identify if the load was successful or not. If it is not, we do a special handler for it.

> This check happens to break my use-case of this feature, which is to handle SSL
> failures that occur as the result of redirects (e.g. https://hotmail.com). When
> the failure occurs m_loadSucceeded is not yet true, and won't be until the ssl
> failure is accepted by the user.

so it is not TRUE yet BUT load has not finished ... hum ... right I will think of something for it. we could have another bug for it, maybe
------- Comment #21 From 2009-07-29 08:21:43 PST -------
> > This check happens to break my use-case of this feature, which is to handle SSL
> > failures that occur as the result of redirects (e.g. https://hotmail.com). When
> > the failure occurs m_loadSucceeded is not yet true, and won't be until the ssl
> > failure is accepted by the user.
> 
> so it is not TRUE yet BUT load has not finished ... hum ... right I will think
> of something for it. we could have another bug for it, maybe

filed bug 27804