Bug 72836 – REGRESSION(r100691): Safari error pages and Growl notifications fail to load stylesheets

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

[Mark Rowe (bdash)]

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.

[Mark Rowe (bdash)]

Created attachment 115995 [details]
Before

[Mark Rowe (bdash)]

Created attachment 115997 [details]
After

[Adam Barth]

How can I reproduce the issue?

[Adam Barth]

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?

[Mark Rowe (bdash)]

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.

[Adam Barth]

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?

[Mark Rowe (bdash)]

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.

[Adam Barth]

Thanks.  Will try.

[Mark Rowe (bdash)]

Hopefully you’re also aware of the run-webkit-app script!

[Adam Barth]

> Hopefully you’re also aware of the run-webkit-app script!

Nope!  That looks very useful for this issue.  Thanks.

[Adam Barth]

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.

[Mark Rowe (bdash)]

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.

[Mark Rowe (bdash)]

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.

[Adam Barth]

Thanks.  I have the repro in Safari now.

[Adam Barth]

I have a fix.  Working on tests now.

[Adam Barth]

Created attachment 116004 [details]
Patch

[WebKit Review Bot]

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

[Adam Barth]

Created attachment 116010 [details]
Patch for landing

[WebKit Review Bot]

Comment on attachment 116010 [details]
Patch for landing

Clearing flags on attachment: 116010

Committed r100877: <http://trac.webkit.org/changeset/100877>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.