Bug 14298

Summary: 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: textEncodingName: 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 element: <script type="text/javascript" src="test.js"></script> then the full URL that is used will be "file://localhost//Users/rmanbert/something/test.js" 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 the app for security reasons. The easiest way to load a JavaScript library 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 view. I use JavaScript libraries that are loaded by the HTML, so I need to 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 error. 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. Regression: This works as expected in WebKit frameworks released with 10.4.x. It does not work as expected in the nightly build. Notes: The demonstration XCode project is in the attached file "WebKitBadBaseUrl.zip". I was advised on the webkit-dev mailing list to file bugs with Apple and here, so that's what I'm doing.