Bug 27296 - [Qt] Some changes to webpage by javascript triggered by signals don't take effect immediately
Summary: [Qt] Some changes to webpage by javascript triggered by signals don't take ef...
Status: RESOLVED WORKSFORME
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Linux
: P2 Normal
Assignee: QtWebKit Unassigned
URL:
Keywords: Qt
: 29574 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-07-15 06:40 PDT by Ori Avtalion (salty-horse)
Modified: 2014-04-24 16:45 PDT (History)
6 users (show)

See Also:


Attachments
Test-case - Qt project (1.50 KB, application/gzip)
2009-07-15 06:40 PDT, Ori Avtalion (salty-horse)
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ori Avtalion (salty-horse) 2009-07-15 06:40:49 PDT
Created attachment 32781 [details]
Test-case - Qt project

Tested with r45855 of QtWebKit with Qt 4.5.2.

1. Create a QWebView and add a QObject to its javascript.
2. Connect a javascript function to a signal on QObject.
3. Emit the signal, and have the handler makes a change to the document's background color.

Results:
The color changes to the page will not take effect until one of the following:
*) Hover over the widget with the mouse cursor.
*) Make a dom manipulation to the document (before or after the css change).
*) Cause an alert.

The attached test-case (a qt project) has a button and a webview.
clicking on the button prints a message to stdout (via the javascript object) and should cause the webview to turn blue.

It doesn't turn blue until hovering over it with the mouse.

In the source code, the handler function has two comments with dom manipulations before and after the css change.
Uncommenting any of them will cause the color to change immediately without a mouse hover.
Comment 1 Chris Hills 2009-07-15 06:46:05 PDT
Confirmed on linux-g++-32 with Qt 4.5.2 and QtWebKit r45855.
Comment 2 Ori Avtalion (salty-horse) 2009-07-16 08:54:33 PDT
On further examination, this is not isolated to style changes.

For example, having the handler add several <p> elements exhibits the same problem:

var items= [1,2,3];
for (i = 0; i < items.length; i++) {
	p = document.createElement('p');
	t = document.createTextNode(String(i));
	p.appendChild(t);
	document.getElementsByTagName('body')[0].appendChild(p);
}
Comment 3 Tor Arne Vestbø 2009-09-21 08:38:15 PDT
*** Bug 29574 has been marked as a duplicate of this bug. ***
Comment 4 Kent Hansen 2010-03-10 08:05:14 PST
Works for me with QtWebKit from 4.6 staging (what will be 4.6.3). Haven't checked if it works with existing 4.6 releases.
Comment 5 Jędrzej Nowacki 2010-03-22 08:13:44 PDT
(In reply to comment #4)
> Works for me with QtWebKit from 4.6 staging (what will be 4.6.3). Haven't
> checked if it works with existing 4.6 releases.

It works for me on Debian/testing (32) with QtWebkit from 4.7 branch (trunk). I think that is safe to say that the issue is fixed in the trunk. 

Ori, could you reproduce it with a newer Qt?

I'm closing this bug for now, if the bug is still valid please add comment to it and I will reopen it.
Comment 6 Ori Avtalion (salty-horse) 2010-04-02 08:55:24 PDT
Confirmed fixed in Ubuntu's 4:4.6.2-0ubuntu3
Comment 7 Darin Adler 2014-04-24 16:45:02 PDT
Moving all JavaScriptGlue bugs to JavaScriptCore. The JavaScriptGlue framework itself is long gone. And most of the more recent bugs put in this component were put there by people who thought this was for some other aspect of “JavaScript glue” and have nothing to do with the actual original reason for the existence of this component, which was an OS-X-only framework named JavaScriptGlue.