[Webkit-unassigned] [Bug 14298] REGRESSION: Wrong base URL used for pages loaded by custom protocol handler
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Fri Jan 25 00:11:54 PST 2019
Clark Kent <airlinesphonenumber888 at gmail.com> changed:
What |Removed |Added
CC| |airlinesphonenumber888 at gmai
--- Comment #13 from Clark Kent <airlinesphonenumber888 at gmail.com> ---
(In reply to Rush Manbert from comment #0)
> In the current shipping version of the WebKit framework, if I load the HTML
> for a web page using a custom protocol and set my desired base URL in the
> NSURLResponse by calling:
> [NSURLResponse initWithURL: MIMEType: expectedContentLength:
> then that base URL is used to resolve any relative resource references in
> the loaded HTML. For instance, if I set the base URL to
> "file://localhost//Users/rmanbert/something/" and my HTML contains this
> then the full URL that is used will be
> In the nightly build of WebKit, this behavior is different. It appears that
> the base URL I set in my NSURLResponse is being ignored, and the base URL
> from the NSURLRequest is being used instead. Given the same example above,
> if the NSURLRequest that I retrieve in my startLoading method of my protocol
> handler has a URL of the form "special://loadString/", but I set the URL in
> the NSURLResponse as I did above, then when my script element is processed,
> WebKit resolves the relative reference as "special://loadString/test.js".
> I rely on being able to set the base URL in my startLoading method, and this
> change in behavior has broken my app. I also believe it is incorrect
> behavior because people may use custom protocols to implement all sorts of
> different content loading schemes. Consider a case where different
> "special://" URLs are used as selectors for HTML content that is baked into
> from within the HTML would be to use a relative URL and manage the base URL
> in the startLoading method. It would be entirely reasonable to set the base
> URL to reference the application bundle resource folder, but you certainly
> would not want the base URL to be something like "special:///selector1".
> In my case, I have an app that must run on the Mac and on Windows. I have a
> custom markup language that extends XHTML. Displaying my content relies on
> transforming the XHTML source with XSLT, as well as performing other
> manipulations on the DOM tree. In order to minimize browser-related
> problems, I use libxml and libxslt to process my source into a HTML string,
> and I use a custom protocol handler to load the HTML string into my WebKit
> control the base URL.
> Steps to Reproduce:
> I have attached (Well, I hope I will be able to attach) a sample project in
> the file "WebKitBadBaseUrl.zip" that demonstrates the problem. It is based
> on Apple's Special Picture Protocol sample project, and I have modified it
> to simulate the way my application loads its web pages. The basic method for
> loading a page with a URL of the form "special:///file.html" is to read the
> contents of the file into a string. This simulates my rendering process. I
> then put the HTML string, plus a string that represents the path portion of
> the desired base URL into a NSDictionary, which I attach to a new
> NSURLRequest. This request carries the URL "something://loadString/", which
> is exactly what my real application does. We then rely on the startLoading
> method in SpecialProtocol.m to extract the HTML string and the base URL
> path. The string becomes the returned data and the path gets incorporated
> into a file: URL to make the desired base URL.
> The HTML contains a <script> tag that references a file that is stored in
> the application bundle resources folder. If the base URL works as expected,
> the web page is displayed. It contains a single line of text. If the base
> URL does not get set as desired, then this is detected in:
> -(NSURLRequest *)webView:(WebView *)sender resource: willSendRequest:
> redirectResponse: fromDataSource:
> in MyController.m. It displays an alert and exits the program with an error.
> To demonstrate proper and improper behavior:
> 1) Build the project for Debug under OS X 10.4.x
> 2) Run the program and note that the web page is displayed. It displays the
> text "Content from test.html". This is the proper behavior because the
> relative reference of "test.js" in the HTML was resolved to the proper file
> URL for the test.js file stored in the application bundle resource folder.
> 3) Now we need to make the application run with the nightly build WebKit.
> Here is one method:
> a) Go to the SpecialPictureProtocol project window and open the
> "Executables" section
> b) Right click on SpecialPictureProtocol and select "Get Info" from the
> drop down menu
> c) Click on the "Arguments" tab
> d) Add two environment variables in the lower panel. Their names and
> values are as follow:
> WEBKIT_UNSET_DYLD_FRAMEWORK_PATH YES
> DYLD_FRAMEWORK_PATH $(PROJECT_DIR)/WebKit.app/Contents/Resources
> See the file CustomExecutableArgumentsSettings.tiff in the project
> directory for a screenshot.
> 4) Once the environment variables have been set, run the application again.
> This time you should see an error alert saying that there is a base URL
> Expected Results:
> I expected the base URL that I set in my startLoading method to be used when
> resolving relative URLs within the loaded HTML.
> Actual Results:
> The "dummy" special protocol URL was used as the base URL. This is the URL
> that was in the NSURLRequest that caused us to invoke startLoading.
> This works as expected in WebKit frameworks released with 10.4.x. It does
> not work as expected in the nightly build.
> The demonstration XCode project is in the attached file
> I was advised on the webkit-dev mailing list to file bugs with Apple and
> here, so that's what I'm doing.
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-unassigned