Bug 29012 – [Qt] Add signals informing about operations on DOM

• Status: RESOLVED
• Resolution: INVALID
• Component: WebKit Qt

[Piotr Dobrogost]

QtWebKit is missing API that would tell when DOM manipulation was started/finished or if it's being performed. loadStarted()/loadFinished() signals of QWebFrame (and QWebPage) are not appropriate as there are async requests (AJAX) which do not change url so they do not trigger these signals at all. And observing requests with custom QNetworkAccessManager is not enough as one does only know when some request was finished and not if DOM is ready (DOM could have been modified as a part of handling response).

[Benjamin Poulain]

How would WebKit know if DOM manipulation is finished?

Sending a signal every time the dom is modified or every time javascript is entered would kill performance.

[Antonio Gomes]

what about sending a set of signals ? (onload, focus, onpageshow/hide, and friends, excuding heavy ones like "DOMModified")

i think is'd gets more power to the API, towards making it really usable for web apps dev, w/o much of hacks.

(In reply to comment #1)
> How would WebKit know if DOM manipulation is finished?
> 
> Sending a signal every time the dom is modified or every time javascript is
> entered would kill performance.

[Benjamin Poulain]

> what about sending a set of signals ? (onload, focus, onpageshow/hide, and
> friends, excuding heavy ones like "DOMModified")
>
> i think is'd gets more power to the API, towards making it really usable for
> web apps dev, w/o much of hacks.

I don't like the idea of systematic signals because it is gonna reduce performance.

That remind me of something. What about pseudo-connection between DOM events and Qt's slots?
Something like: "QWebElement::connect(char *jsEventName, QObject *object, char* slot)". This has never been investigated, someone should check if it is possible to plug ourself in the DOM's event system.

[Kenneth Rohde Christiansen]

You could basically do this manually. Expose a QObject to the JS environment, hook up event listeners to call back methods on the QObject and emit the needed signals.

[Antonio Gomes]

(In reply to comment #4)
> You could basically do this manually. Expose a QObject to the JS environment, hook up event listeners to call back methods on the QObject and emit the needed signals.

Doing it manually would work, yes. An example or update docs about it would ROCK.