red outline gets drawn when web inspector is closed and new pages load. it also overlaps on other apps when webkit is in the background and the page finishes loading.
Created attachment 8045 [details] a screenshot of the overlap.
Confirmed with r14125. To reproduce: 1) Open WebKit.app (or Safari w/WebKit) 2) Right-click, Inspect Element. 3) Close the inspector. 4) Hit refresh, and note that the red outline is drawn around the page after it loads.
(In reply to comment #2) > 4) Hit refresh, and note that the red outline is drawn around the page after it > loads. Also, if you bring other Safari windows or even windows from other application to the front (so that the previously inspected window is now partially or totally hidden), the red outline is drawn over ALL windows! Makes me wonder what would happen if the window were sent to the dock when the red outline was drawn!
(In reply to comment #3) > Makes me wonder what would happen if the window were sent to the dock when the > red outline was drawn! The red outline is drawn where the window would have been when it's in the dock.
Created attachment 8810 [details] Patch This is a fix for the "outline reappears" bug. The problem with the outline being in front of other windows is a separate issue (it is currently in a window level above all other normal windows instead of being a child window).
(In reply to comment #5) > [...] The problem with the outline > being in front of other windows is a separate issue (it is currently in a > window level above all other normal windows instead of being a child window). Filed Bug 9403 for the above issue.
Comment on attachment 8810 [details] Patch r=me
Committed r14812.
It's not right to unconditionally use hostWindow. The client is not obligated to set hostWindow at all. For Safari, there will always be a hostWindow. But in general, the window you're in is either the actual physical window, or if that's nil, the hostWindow. Setting up an observer that tracks this as the hostWindow value changes and the window possibly changes as well is an exercise left to the coder.
(In reply to comment #9) Tracking the WebView's window and hostWindow turned out to be complicated and inadequate for framesets. Bug 9479 suggests a WebFrame-based approach.