Bug 159480 – DRT and WKTR should consistently encode URLs when printing frame load delegates and back forward lists

• Status: RESOLVED
• Resolution: WONTFIX
• Component: New Bugs

[Andy Estes]

DRT and WKTR should consistently encode URLs when printing frame load delegates and back forward lists

[Andy Estes]

Created attachment 282921 [details]
Patch

[Alex Christensen]

Comment on attachment 282921 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=282921&action=review

This seems reasonable, but I'm not aware of what problem this is trying to solve.

> Tools/WebKitTestRunner/Configurations/InjectedBundle.xcconfig:33
> +OTHER_LDFLAGS_PLATFORM[sdk=iphone*] = -framework CFNetwork -framework CoreFoundation -framework CoreGraphics -framework Foundation -framework UIKit -framework WebCore;

I thought we couldn't link with WebCore directly unless we were WebKit or WebKitTestSupport

[Alex Christensen]

*WebCoreTestSupport

[Andy Estes]

(In reply to comment #2)
> Comment on attachment 282921 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=282921&action=review
> 
> This seems reasonable, but I'm not aware of what problem this is trying to
> solve.

The problem is that the URLs printed by DRT and WKTR would differ by URL encoding, making it impossible to have a test result that works for both test harnesses.

> 
> > Tools/WebKitTestRunner/Configurations/InjectedBundle.xcconfig:33
> > +OTHER_LDFLAGS_PLATFORM[sdk=iphone*] = -framework CFNetwork -framework CoreFoundation -framework CoreGraphics -framework Foundation -framework UIKit -framework WebCore;
> 
> I thought we couldn't link with WebCore directly unless we were WebKit or
> WebKitTestSupport

That's true. I'm not sure why this worked, but I can probably link against WebKit instead.

[Build Bot]

Comment on attachment 282921 [details]
Patch

Attachment 282921 [details] did not pass mac-wk2-ews (mac-wk2):
Output: http://webkit-queues.webkit.org/results/1637017

Number of test failures exceeded the failure limit.

[Build Bot]

Created attachment 282929 [details]
Archive of layout-test-results from ews105 for mac-yosemite-wk2

The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: ews105  Port: mac-yosemite-wk2  Platform: Mac OS X 10.10.5

[Build Bot]

Comment on attachment 282921 [details]
Patch

Attachment 282921 [details] did not pass ios-sim-ews (ios-simulator-wk2):
Output: http://webkit-queues.webkit.org/results/1637009

Number of test failures exceeded the failure limit.

[Build Bot]

Created attachment 282931 [details]
Archive of layout-test-results from ews126 for ios-simulator-wk2

The attached test failures were seen while running run-webkit-tests on the ios-sim-ews.
Bot: ews126  Port: ios-simulator-wk2  Platform: Mac OS X 10.11.4

[Build Bot]

Comment on attachment 282921 [details]
Patch

Attachment 282921 [details] did not pass mac-ews (mac):
Output: http://webkit-queues.webkit.org/results/1637037

New failing tests:
fast/loader/subframe-navigate-during-main-frame-load.html
fast/history/history-back-initial-vs-final-url.html
fast/history/back-from-page-with-focused-iframe.html

[Build Bot]

Created attachment 282933 [details]
Archive of layout-test-results from ews103 for mac-yosemite

The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: ews103  Port: mac-yosemite  Platform: Mac OS X 10.10.5

[Build Bot]

Comment on attachment 282921 [details]
Patch

Attachment 282921 [details] did not pass mac-debug-ews (mac):
Output: http://webkit-queues.webkit.org/results/1637067

New failing tests:
fast/loader/subframe-navigate-during-main-frame-load.html
fast/history/history-back-initial-vs-final-url.html
fast/history/back-from-page-with-focused-iframe.html

[Build Bot]

Created attachment 282935 [details]
Archive of layout-test-results from ews114 for mac-yosemite

The attached test failures were seen while running run-webkit-tests on the mac-debug-ews.
Bot: ews114  Port: mac-yosemite  Platform: Mac OS X 10.10.5

[Andy Estes]

(In reply to comment #4)
> (In reply to comment #2)
> > Comment on attachment 282921 [details]
> > Patch
> > 
> > View in context:
> > https://bugs.webkit.org/attachment.cgi?id=282921&action=review
> > 
> > > Tools/WebKitTestRunner/Configurations/InjectedBundle.xcconfig:33
> > > +OTHER_LDFLAGS_PLATFORM[sdk=iphone*] = -framework CFNetwork -framework CoreFoundation -framework CoreGraphics -framework Foundation -framework UIKit -framework WebCore;
> > 
> > I thought we couldn't link with WebCore directly unless we were WebKit or
> > WebKitTestSupport
> 
> That's true. I'm not sure why this worked, but I can probably link against
> WebKit instead.

Not totally sure I understand why this is needed, but DumpRenderTree and TestWebKitAPI also link directly against WebCore on iOS. Maybe this is ok if you also link against WebCoreTestSupport? Anyway, I'm going to keep this in.

[Andy Estes]

Turns out that WebCore::encodeWithURLEscapeSequences() and NSURL don't agree on the characters to percent encode (e.g. NSURL encodes '{' and '}' but URL doesn't), so I don't think this is going to work.

I'm going to take a different approach.