Bug 54618 - Web Inspector: Need renderer hint on implementing hovered node highlight in WebCore.
Summary: Web Inspector: Need renderer hint on implementing hovered node highlight in W...
Status: RESOLVED WONTFIX
Alias: None
Product: WebKit
Classification: Unclassified
Component: Web Inspector (Deprecated) (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-02-16 22:35 PST by Pavel Feldman
Modified: 2011-08-08 22:47 PDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Pavel Feldman 2011-02-16 22:35:15 PST
Summarizing chats that I've had on the IRC. Background:

When you hover over an element in inspector, we paint node highlight. Different ports handle it differently, all ultimately calling inspector's drawNodeHighlight defined in WebCore:

- Mac uses floating NSView in WebNodeHighlightView
- Windows uses floating native window in WebNodeHighlight
- GTK and Chromium simply issue repaint and stick inspector's drawNodeHighlight into their paint routines.
- WebKit2 is pending implementation

I'd like to unify the approaches and keep all the code in the WebCore. There are two scenarios where naive approach of putting drawNodeHighlight into FrameView does not work:
- plugins that are on top of the screen
- accelerated compositing

We can give up the plugins one, but compositing still requires special handling.

I am a rendering idiot and reaching out for your hints. As I see, we could do two things:
1. Bump element's zindex on hover in its style and call highlight code from the RenderObject
2. Somehow have additional RenderLayer that would paint highlight

(1) has a side-effect of bringing node above other elements, but sounds simpler. It might be considered as either feature or a regression, I am not sure.
(2) would be simply perceived as no regressions.

On a side note, there is a pending request to make inspector highlight follow the moving / transforming elements, so (1) sounds more feasible to me, but I know nothing about rendering.

What do I miss?
Comment 1 Simon Fraser (smfr) 2011-02-17 09:12:06 PST
 >1. Bump element's zindex on hover in its style and call highlight code from the RenderObject

That wont' work.

> 2. Somehow have additional RenderLayer that would paint highlight

I don't think you want that either.

When accelerated compositing is off, you could get away with painting something "last" in the painting order. See ScrollView for some code that does this for overlay scrollbars and the pan indicator.

When accelerated compositing is on, you'll need to render the highlight into its own GraphicsLayer which is above everything else. WebKit2 already has a notion of an overlay layer (it's used for the Find highlight), but we'd need to pipe something through for WebKit1.

It would be nice if we could share the same "overlay" logic whether or not compositing is on, and have the GraphicsLayer part be hidden.
Comment 2 Pavel Feldman 2011-08-08 22:47:52 PDT
Implemented in WebKit.