[Webkit-unassigned] [Bug 30788] New: HistoryController does not handle some opaque URLs correctly

[bugzilla-daemon at webkit.org]

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

           Summary: HistoryController does not handle some opaque URLs
                    correctly
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: PC
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: Normal
          Priority: P2
         Component: History
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: alex at igalia.com
                CC: ap at webkit.org, sam at webkit.org, xan.lopez at gmail.com


Created an attachment (id=41890)
 --> (https://bugs.webkit.org/attachment.cgi?id=41890)
Test reproducing the problem

This bug comes from the bug 30724, in the comment 2 it is explained the
situation that is currently causing problems with the gtk+ DRT when testing
opaque-base-url.html, but that it seems it could be reproduced with the test
attached to this bug in other platforms. I've added the main authors of the
opaque-base-url.html test to the CC, thanks in advance for the help.

The test tries to reproduce the error in other platforms, not just gtk+, trying
to do a similar action done in the gtk+ DRT. Basically this kind of opaque urls
are causing problems when the state is saved in the HistoryController, it is
checked if that item is in current document and that tries to create a URL
using an opaque URL that hits the checkEncodedString assertion about the first
character in an url. I guess even this being an invalid URL (we should remove
that from the opaque test then) we should handle the situation without reaching
the assertion.

Can someone check the test with other platforms and see if the problem is
there? I guess the patch should control the current document condition in case
of this kind of opaque URLs, not sure if just avoiding saving or setting as
current because there is not URL.

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