After updating my system WebKit frameworks past r100691 I’m seeing that Growl's notification alerts appear to be failing to load any style information. See the before / after screenshots.
Created attachment 115995 [details] Before
Created attachment 115997 [details] After
How can I reproduce the issue?
The problem might be on Line 127 if SchemeRegistry::shouldTreatURLSchemeAsLocal is overbroad and should be restricted to "file". Can you tell me the URL of the document displayed in the Growl notification?
You can reproduce the issue by running Growl against tip of tree WebKit and triggering any notification. The app I was testing with was UnPlugged, since it will trigger a notification simply by plugging / unplugging from power. I have no idea what URLs Growl is using for its notifications.
Ok. I have Colloquy, which apparently uses Growl, and I have a tip of tree build of WebKit. How do I wire the two up to each other to exhibit the problem? I can try hacking up ./Tools/Scripts/run-safari to run Colloquy via runMacWebKitApp. Is that the right approach?
With Growl 1.3.1 all I did was kill the Growl process, then run /Applications/Growl.app with DYLD_FRAMEWORK_PATH set to my build directory.
Thanks. Will try.
Hopefully you’re also aware of the run-webkit-app script!
> Hopefully you’re also aware of the run-webkit-app script! Nope! That looks very useful for this issue. Thanks.
I was able to run Colloquy with tip-of-tree WebKit (verified using gdb), but the notifications looked fine. Growl claims to be used by Firefox, but they really mean by a Firefox addon, which doesn't work in modern versions of Firefox. I installed UnPlugged, but there doesn't appear to be any way to trigger a notification with this software on my Mac Pro because my Mac Pro doesn't have a battery (i.e., unplugging it turns it off). There are a number of paths forward: 1) If you can give me repro instructions I'm able to follow, I can debug the issue locally. 2) If you're willing to iterate with me, I can give you a couple patches to try. That will help us narrow down the problem and arrive at a solution. 3) I can try fixing the bug blind based on what you've told me so far. (This is really just approach 2 with a longer iteration cycle, but perhaps less work on your part.) Please let me know how you'd like to proceed.
This also appears to reproduce in Safari, which may make reproducing and debugging easier. Loading <http://this.does.not.exist.apple.com/> in the latest WebKit nightly running with Safari 5.1.1 results in an unstyled error page.
Note that in the Growl case it’s not the app *using* Growl that needs to run with tip of tree WebKit, it’s the separate Growl process that displays the notification that does.
Thanks. I have the repro in Safari now.
I have a fix. Working on tests now.
Created attachment 116004 [details] Patch
Comment on attachment 116004 [details] Patch Attachment 116004 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/10472426 New failing tests: fast/xmlhttprequest/xmlhttprequest-nonexistent-file.html
Created attachment 116010 [details] Patch for landing
Comment on attachment 116010 [details] Patch for landing Clearing flags on attachment: 116010 Committed r100877: <http://trac.webkit.org/changeset/100877>
All reviewed patches have been landed. Closing bug.