[Webkit-unassigned] [Bug 29248] New: [Qt] [API] Make it possible to have 'invisible' loads

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=29248

           Summary: [Qt] [API] Make it possible to have 'invisible' loads
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: PC
        OS/Version: All
            Status: NEW
          Keywords: Qt
          Severity: Normal
          Priority: P2
         Component: WebKit Qt
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: tonikitoo at gmail.com
                CC: hausmann at webkit.org, ariya.hidayat at trolltech.com,
                    vestbo at webkit.org, kenneth.christiansen at openbossa.org


For substitution loads (e.g. setHtml, setContent and friends) it could be a
nice add to the API to make it possible to have what we've calling 'invisible'
loads. Feature basically consists in loading a given HTML content (for now lets
consider it a QString):

1) w/o necessarely changing WebCore's backforward and global history content.
2) w/o getting loading signals emitted

 ==========
* Use case *
 ==========

1) user enter a valid url (http://www.google.com) then enters any non-existent
url (e.g. http://xxx.yyy).
   The client browser might want to feedback the user about the loading error,
maybe by calling setHtml() passing in
   some loading error template page.
   The problem is that currently setHtml starts a completely new load. so in
our backforward history content one would end up w/
   -> google.com -> xxx.yyy -> baseUrl passed in to setHtml, if any.

   Desired backforward content is:
   -> google.com -> xxx.yyy (the error page shown). So calling RELOAD, back or
forward would work as user expect.

 ==================
* Proposed solution *
 ==================

A working solution  (not ready yet for a final review) I would like to request
comments for is attached (patch v0.1). It basically overloads the existenting
QWebFrame::setHtml method, extending the way it works if some parameters are
passed in. If the approach is good, it could get into setContent() method too
in the same way.

Some points are still to be properly defined, for example: About (2), I am sure
if not emitting all load signals is good, or just 'urlChanged' (as currently in
the patch).

please comments are welcome.

ps: not autotests yet, but existent tests passed.
ps: no  difference in layout-test results after the changes in webcore.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.