[Webkit-unassigned] [Bug 14738] New: Local file loaded with custom protocol cannot load local flash file

[bugzilla-daemon at webkit.org]

http://bugs.webkit.org/show_bug.cgi?id=14738

           Summary: Local file loaded with custom protocol cannot load local
                    flash file
           Product: WebKit
           Version: 522+ (nightly)
          Platform: Macintosh
        OS/Version: Mac OS X 10.4
            Status: UNCONFIRMED
          Severity: Major
          Priority: P1
         Component: New Bugs
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: rush at manbert.com


Summary:
I have a local html file that loads a local flash file. If I load the html file
using the file: protocol, it loads and plays the flash file without any
problems.

If, on the other hand, I load the html file using a custom protocol, the flash
file does not get loaded. If I implement:
-(void)webView:(WebView *)sender addMessageToConsole:(NSDictionary *)dictionary
and register as the UI delegate, then I see addMessageToConsole being called
with the message: "Not allowed to load local resource file:
path/to/flash/file".

If I run this test against the currently shipping WebKit the flash file is
loaded and played in either case. It is broken in the nightly build.

Steps to Reproduce:
I have attached a test project that demonstrates this problem. It is based on
the SpecialPictureProtocol demo project from Apple. I have modified it as
follows:
1) The first page that loads has 2 links. One says "Load Flash Demo Test from
disk file". When clicked, it loads a file called FlashDemo2Test.html that is in
nthe app's resource folder. The second link says "Load Flash Demo Test from
HTML string". When clicked, this loads the contents of FlashDemo2Test.html via
this URL:
    special://localhost/./FlashDemo2Test.html

2) The "special:" protocol handler opens and reads the contents of
FlashDemo2Test.html. It then converts all of the relatie file references in the
HTML string into absolute file URLs. The file includes a <base> element. Its
path is modified to be the full file: protocol path to the app's resource
folder.

3) The contents of FlashDemo2Test.html has a Back link that goes back to
test6.html. The "Reset" button does the same.

To demonstrate the problem:
a) Build and run the project against the currently shipping Apple WebKit
framework.
b) Click the top link to load the demo file from disk.
c) Click on the button displayed in the Flash animation to make it do its
thing.
d) Click the Reset button to return to the main page
e) Click on the bottom link to load the4 HTML string
f) Examine the Xcode Run Log window to see the actual HTML string that was
returned by the protocol handler.
g) Click on the buttons displayed by the animation to see that it works.
h) Stop and run the application again against the nightly build WebKit
i) Click on the top link to load from disk. Note that things still work as
expected.
j) Click the Reset button to return to the main page
k) Click on the bottom link to load the HTML string.
l) Note the error report and tha fact that the flash file doesn't load.
m) Examine the Xcode Run Log to see the HTML string that was returned by the
protocol handler. Looks pretty similar to what was returned before, doesn't it?
n) Note that the Back link doesn't work either and generates the same error
message.

Expected Results:
I expected the flash content to load. I expected that the Back link would work.
The URL that loaded the file content with the custom protocol handler specifies
host as "localhost". I have explicitly specified a base URL in the head of the
returned HTML. Why can't this HTML load local resources?

Actual Results:
The local resource files do not get loaded.

Regression:
This does not occur in the currently shipping Apple WebKit framework. I am
running 10.4.10.

This error does occur in the nightly build of WebKit. My WebCore Xcode project
has "Current Library Version" set to 522.9

Notes:
The demo project is in "FlashWillNotLoad.zip"


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