Bug 56354 - Web Inspector: empty, non-functional window
Summary: Web Inspector: empty, non-functional window
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Web Inspector (Deprecated) (show other bugs)
Version: 528+ (Nightly build)
Hardware: Mac (Intel) OS X 10.6
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-03-14 19:14 PDT by Jeff Johnson
Modified: 2011-03-28 22:09 PDT (History)
11 users (show)

See Also:


Attachments
Patch (2.19 KB, patch)
2011-03-24 05:38 PDT, Jeff Johnson
no flags Details | Formatted Diff | Diff
Patch (2.20 KB, patch)
2011-03-25 06:28 PDT, Jeff Johnson
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jeff Johnson 2011-03-14 19:14:34 PDT
I'm using a Debug build of WebKit svn r81082 on Mac OS X 10.6.6, Safari 5.0.4.

When I load a web page and open the web inspector, the inspector is just an empty window. There's a search field and buttons, but nothing does anything.

When I open "WebKit/WebKitBuild/Debug/WebCore.framework/Versions/A/Resources/inspector/inspector.html" in Safari running the system WebKit, Safari's normal web inspector Console gives this error:

TypeError: Result of expression 'this.classList' [undefined] is not an object.
Comment 1 Jeff Johnson 2011-03-14 19:15:09 PDT
Joe Peck said it's probably the result of https://bugs.webkit.org/show_bug.cgi?id=56096
Comment 2 Jeff Johnson 2011-03-14 21:35:01 PDT
Actually, I can reproduce this bug with svn r80830, so it wasn't broken in 80831.
Comment 3 Joseph Pecoraro 2011-03-14 22:15:14 PDT
Oh, that makes sense if classList was not available in Safari 5.0.4. I thought it was.
Comment 4 Jeff Johnson 2011-03-14 23:21:51 PDT
The cause is actually http://trac.webkit.org/changeset/70622/trunk along with associated build fixes http://trac.webkit.org/changeset/70623/trunk and http://trac.webkit.org/changeset/70633/trunk

To reproduce:
defaults write com.apple.Safari WebKitLocalStorageEnabledPreferenceKey -bool false

The file "WebKit/Source/WebCore/inspector/front-end/Settings.js" needs to check "window.localStorage != null" before using it.
Comment 5 Pavel Feldman 2011-03-14 23:24:37 PDT
> To reproduce:
> defaults write com.apple.Safari WebKitLocalStorageEnabledPreferenceKey -bool false

why would you do this?
Comment 6 Jeff Johnson 2011-03-15 05:49:08 PDT
(In reply to comment #5)
> > To reproduce:
> > defaults write com.apple.Safari WebKitLocalStorageEnabledPreferenceKey -bool false
> 
> why would you do this?

LOL. Why wouldn't I do it? Why do people disable cookies? :-)
Comment 7 Jeff Johnson 2011-03-24 05:38:24 PDT
Created attachment 86759 [details]
Patch
Comment 8 Pavel Feldman 2011-03-24 11:17:54 PDT
Comment on attachment 86759 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=86759&action=review

Thanks for fixing this. I have to put r- for the poor email in the changelog + nit on the null comparison.

> Source/WebCore/ChangeLog:1
> +2011-03-24  Jeff Johnson  <lapcatsoftware.com>

This should contain your email.

> Source/WebCore/inspector/front-end/Settings.js:117
> +        if (window.localStorage === null)

I'd rather use window.localStorage == null in order to allow undefined value. Have you checked that localStorage is null both for v8 and jsc bindings?
Comment 9 Jeff Johnson 2011-03-24 14:31:55 PDT
(In reply to comment #8)
> (From update of attachment 86759 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=86759&action=review
> 
> Thanks for fixing this. I have to put r- for the poor email in the changelog + nit on the null comparison.
> 
> > Source/WebCore/ChangeLog:1
> > +2011-03-24  Jeff Johnson  <lapcatsoftware.com>
> 
> This should contain your email.

I actually left the full address out on purpose, because after my last patch, which did contain an email address, I started receiving a ton of spam at that address, whereas I had never received spam at that address before. Is there some way I can leave out the email? I'd rather be anonymous than spammed. ;-)

> > Source/WebCore/inspector/front-end/Settings.js:117
> > +        if (window.localStorage === null)
> 
> I'd rather use window.localStorage == null in order to allow undefined value. Have you checked that localStorage is null both for v8 and jsc bindings?

I don't think there would be a difference between V8 and JSC, because the value comes from DOMWindow::sessionStorage():

https://trac.webkit.org/browser/trunk/Source/WebCore/page/DOMWindow.cpp

That said, I'm not opposed to switching operators if you prefer.

I should also note that I've filed this related bug:

https://bugs.webkit.org/show_bug.cgi?id=56703

If the linked bug is implemented, then we'd need to wrap a try around the check as opposed to (or in addition to) checking for null. However, I'd rather fix the web inspector now and possibly revise it later if and when the SECURITY_ERR change is implemented. I don't know how much opposition there would be to throwing a SECURITY_ERR.
Comment 10 Jeff Johnson 2011-03-24 14:43:24 PDT
Typo in the above, I meant DOMWindow::localStorage rather than DOMWindow::sessionStorage.
Comment 11 Pavel Feldman 2011-03-25 02:37:36 PDT
http://www.webkit.org/coding/contributing.html#changelogs claims there should be an email. I'd rather not violate it. I see opendarwin at lapcatsoftware.com in the comments titles, so it is already available to the spammers...

> I don't think there would be a difference between V8 and JSC, because the value comes from DOMWindow::sessionStorage():
> 
> https://trac.webkit.org/browser/trunk/Source/WebCore/page/DOMWindow.cpp

It is wrapped in the VM-specific JavaScript bindings, but it looks like both engines behave the same way. However, I suspect that compiling WebKit without ENABLE_DOM_STORAGE would result in window.localStorage being undefined, so == is better.

> 
> https://bugs.webkit.org/show_bug.cgi?id=56703
> 
> If the linked bug is implemented, then we'd need to wrap a try around the check as opposed to (or in addition to) checking for null. However, I'd rather fix the web inspector now and possibly revise it later if and when the SECURITY_ERR change is implemented. I don't know how much opposition there would be to throwing a SECURITY_ERR.

Yes, lets keep them separate.
Comment 12 Jeff Johnson 2011-03-25 06:28:58 PDT
Created attachment 86930 [details]
Patch
Comment 13 WebKit Commit Bot 2011-03-28 22:08:56 PDT
Comment on attachment 86930 [details]
Patch

Clearing flags on attachment: 86930

Committed r82191: <http://trac.webkit.org/changeset/82191>
Comment 14 WebKit Commit Bot 2011-03-28 22:09:01 PDT
All reviewed patches have been landed.  Closing bug.