[Webkit-unassigned] [Bug 110524] Add a way to watch pages for elements matching a CSS selector

[bugzilla-daemon at webkit.org]

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


Jeffrey Yasskin <jyasskin at chromium.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #189626|0                           |1
        is obsolete|                            |




--- Comment #3 from Jeffrey Yasskin <jyasskin at chromium.org>  2013-02-22 16:42:30 PST ---
Created an attachment (id=189861)
 --> (https://bugs.webkit.org/attachment.cgi?id=189861&action=review)
Preliminary patch adding a -webkit-callback CSS property

This patch implements Adam's suggestion to just post a task to the main thread, and fixes the style problems.

- I don't have any personal preference about how much to hide -webkit-callback from the web. I can look into hiding it from getComputedStyle; not sure how to prevent web pages from setting it. At the moment, if a web page uses it itself, that does trigger (or suppress) the callback, so embedders need to handle this, but it's straightforward to avoid losing callbacks by putting embedder-relevant uses in user- rather than author- stylesheets. (I'll test this.)
- For the declarativeContent use case, I think it's actually better to suppress callbacks for display:none nodes, although clearly I'll have to document that.

- Re "spurious events", because I'm aggregating these across a task, destroying the RenderStyle and recreating it will cause an extra task to run, but won't send an extra callback to the FrameLoaderClient.
- I'll check with you how to test this against a page cycler.

I still need to write tests and a benchmark proving this helps my use case.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.