Bug 28903 – Web Inspector turns empty on selection

• Component: Web Inspector (Deprecated)
• Status: RESOLVED FIXED

[Ain Tohvri]

1. Select a word on page
2. Right-click "Inspect Element"
3. Web Inspector turns up empty without highlighted source code of the selection

It works on retry BUT while moving up and down on the source code in Inspector, there's no highlighting happening on the page.

OS: Mac OS X 10.6 (Snow Leopard)

[Patrick Mueller]

Need more detail.

What URL did you try?  Any?  

Is this a WebKit nightly?  Some version of Safari?

Can you at least see the panel selection toolbar at the top?  What panel did you land in?  Since you mention "source code", I'm guessing you're in the Scripts panel? 

The last comment makes it sound like everything was working on a reload, except the JavaScript source wasn't highlighted.  Is that JavaScript source file, or HTML file, large?

[Ain Tohvri]

- any URL
- yes, it was nightly
- Inspector turned up nicely as usual, but no code inside it
- no JS, just regular 2-3KB HTML as rendered in browser

[Ain Tohvri]

No such behaviour in the latest nightly. I guess it has been fixed.

[Ain Tohvri]

In the latest nightly (r48139), the bug is again there.

[Patrick Mueller]

Works for me on that nightly.  Tested by bringing up Web Inspector after selecting a word on this page.

[Ain Tohvri]

Works on r48276. I'm afraid it's a random issue or a conflict with some JS in effect on page. Will give it more testing.

[Patrick Mueller]

You were still getting this for ANY URL?  It was reproduceable for http://www.yahoo.com, for instance?

I still not clear on what you are exactly seeing.  The entire Web Inspector window is blank?  Or was it just one or more individual panels, like the Scripts panel, that was blank.

Given the state of the bug (blank-ness), this is may well not work, but you might try it next time this happens.  From within Web Inspector, right click in the window, and select "Inspect Element".  This will launch a Web Inspector on Web Inspector.  From there, bring up the console, and let us know if any messages got posted there, especially exception messages.

[Timothy Hatcher]

Reopen if you still see this, with steps.

[Ain Tohvri]

Created attachment 39508 [details]
Screenshot of empty Inspector

You can tell what's the issue from the screenshot: Inspector turns up empty, console displays no errors.

[Ain Tohvri]

I still see this, steps as described in 1st comment.

I'm afraid it's a conflict with Drupal JS because I discovered this in Drupal backend and I was also fortunate to reproduce it on Drupal.org, e.g. complete the steps at  http://groups.drupal.org/node/13644

I'll attach the screenshot from there shortly.

[Ain Tohvri]

Created attachment 39509 [details]
Screenshot of empty Inspector on Drupal.org

[Ain Tohvri]

Created attachment 39510 [details]
Screenshot of empty Inspector on BBC.co.uk

I've just proven this is also the case elsewhere so it's not anything specific to Drupal. BBC's site breaks as well and it's W3C valid XHTML 1 Strict. Must be something else.

[Patrick Mueller]

(In reply to comment #12)
> Created an attachment (id=39510) [details]
> Screenshot of empty Inspector on BBC.co.uk

Excellent.  I was able to reproduce this now at 

   http://www.bbc.co.uk/

First, I had to dock the inspector, then reload the page.  It appears to only happen when Inspector is docked.  So a work-around for you is to undock the inspector.  Click the little rectangles icon in the bottom left of the inspector pane.

Also, this is only happening with the Elements panel, the other panels come up ok - though I didn't drive through them at all.

[Ain Tohvri]

Strangely enough it displays console.debug() messages on the console though, but no source code in the upper panel.

[Patrick Mueller]

(In reply to comment #14)
> Strangely enough it displays console.debug() messages on the console though,
> but no source code in the upper panel.

It may be strange, but it's not surprising.  The problem is likely that during bring-up of the Elements panel, an exception is occuring, which terminates the processing that would render the page.  Further events are unaffected, at least ones which operate indepdently of the Elements panel itself - the console is independent of the other panels.

I had forgotten when I first reproduced this to bring up an inspector on the inspector, in hopes of catching the presumed exception logging itself on THAT console, but no luck.  Should try running this with a debug build and run-safari in hopes that perhaps something would be getting dumped to stdout/stderr there, but that seems unlikely.  We may be able to use the new WebInspector.log() function to insert some logging in the Elements panel bring-up to help narrow down the problem.  Perhaps wrap the entire Elements bring up in an exception handler?

[Patrick Mueller]

(In reply to comment #10)
> I'm afraid it's a conflict with Drupal JS because I discovered this in Drupal
> backend and I was also fortunate to reproduce it on Drupal.org, e.g. complete
> the steps at  http://groups.drupal.org/node/13644

I can no longer reproduce this on r48398 with the bbc link.  And the drupal link now returns a "500 Internal Server Error" according to curl.

Do you have any other example links that are similarly broken?

[Ain Tohvri]

Here's how to reproduce it again:

1. Go to http://groups.drupal.org/
2. Select a word
3. Right-click 'Inspect Element'

[Timothy Hatcher]

I can't reproduce with the new steps. Is there anything in the system console?

[Patrick Mueller]

(In reply to comment #18)
> I can't reproduce with the new steps. Is there anything in the system console?

I'm able to reproduce this in r48454, but it's intermittent, and usually doesn't happen.  Timing issue?  An inspector inspector's console lists the following error:

   inspector.js:14129

Currently doing a debug build to look into it a bit more.

[Patrick Mueller]

(In reply to comment #19)
> (In reply to comment #18)
> > I can't reproduce with the new steps. Is there anything in the system console?
> 
> I'm able to reproduce this in r48454, but it's intermittent, and usually
> doesn't happen.  Timing issue?  An inspector inspector's console lists the
> following error:
> 
>    inspector.js:14129
> 
> Currently doing a debug build to look into it a bit more.

inspector.js:14129 is ElementsPanel.js - WebInspector.ElementsPanel.prototype._mouseMovedOutOfCrumbs(), which is the target of a DOM "mousemove" event, so unlikely to be the cause of the problem.

Even getting these wasn't consistent; seems like I only got them with the empty Elements panel, but not ALWAYS with the empty Elements panel.

Running a debug version of run-safari from the console, I saw nothing unusual printed out.

[Patrick Mueller]

I'm able to more reliably reproduce this error with the following steps:

- bring up a new WebKit nightly on http://groups.drupal.org/
- select the word "groups" by double-clicking it, in the section titled: "Where Have All The Panels Gone?", first sentence
- context menu, "Inspect Element"
- note that I see the elements here
- close the inspector
- reload the groups.drupal page
- repeat steps of selecting the word "group", down to context menu, "Inspect Element"
- usually get the empty elements pane here, sometimes I have to repeat the process again

[Patrick Mueller]

Created attachment 39697 [details]
instrumented ElementPanel with output

I've added some instrumentation to ElementPanel to trace the method calls made, and collected the traces of a ElementsPanel that comes up, and one that doesn't, in the attachment.  No analysis yet, but good to see they're different.

[Patrick Mueller]

At this point, it appears to me that there are no exceptions occurring, it's just that the DOM elements are not added to the content view, so you get the big white window.  The treeoutline for the elements is actually all set up, it just has no children.

Tracing through this, it appears the cause is that during an ElementPanels.reset() call, InspectorController.isWindowVisible() is returning false, which causes an early return from reset(); if allowed to continue, everything seems to work ok.

Need to figure out who added that check.  Is it just an optimization?  if so, we can just remove the check; if we really shouldn't proceed at this point, perhaps we should queue an event to run the reset again in a short while, in hopes that the window does become visible.  Or perhaps there is a way to get hooked to a "window is now visible" event.  Or perhaps isWindowVisible() is incorrectly returning false at this point.

There is a big timing difference between the first and second runs of the scenario i'm testing; the first run, which works, does all the panel setup and what-not.  The second run does not.  This may mean that the window becomes visible during all that setup time, whereas in the second run, with less work to do, the window is in fact not visible.

[Patrick Mueller]

The isVisible() check was added in bug 6590, comment 11

[Pavel Feldman]

*** Bug 29769 has been marked as a duplicate of this bug. ***

[Pavel Feldman]

(reviewed in https://bugs.webkit.org/show_bug.cgi?id=29769)

Committing to http://svn.webkit.org/repository/webkit/trunk ...
	M	WebCore/ChangeLog
	M	WebCore/inspector/InspectorController.cpp
	M	WebCore/inspector/InspectorController.h
	M	WebCore/inspector/InspectorDOMAgent.cpp
	M	WebCore/inspector/InspectorDOMAgent.h
	M	WebCore/loader/FrameLoader.cpp
	M	WebCore/page/android/InspectorControllerAndroid.cpp
Committed r48798

[Patrick Mueller]

confirmed that the test case described in comment 21 no longer fails (I see the elements page all the time) as of nightly r48908