RESOLVED FIXED 19077
[Qt] Clicking on a link with target=_blank doesn't do anything 
https://bugs.webkit.org/show_bug.cgi?id=19077
Summary [Qt] Clicking on a link with target=_blank doesn't do anything
Marco Barisione
Reported 2008-05-15 07:01:12 PDT
window.open() from js opens a new window but clicking on <a target="_blank" href="#">..</a> doesn't do anything. I will attach a patch ASAP.
Attachments
Show the window containing the newly created QWebPage (1.57 KB, patch)
2008-05-15 07:48 PDT, Marco Barisione 		hausmann: review-
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Marco Barisione
Comment 1 2008-05-15 07:48:35 PDT
Created attachment 21163 [details] Show the window containing the newly created QWebPage Can newPage->view() be null in this case?
Simon Hausmann
Comment 2 2008-05-19 07:14:10 PDT
Comment on attachment 21163 [details] Show the window containing the newly created QWebPage I don't think this is the right place to call show(). dispatchCreatePage() is called from FrameLoader::continueAfterNewWindowPolicy, which shortly afterwards calls FrameLoaderClient::dispatchShow(). That function is currently not implemented and I believe that's where a show() call should go.
Marco Barisione
Comment 3 2008-05-20 02:58:54 PDT
Oh, right. I didn't know of dispatchShow. I will update the patch as soon as possible.
Marco Barisione
Comment 4 2008-05-22 03:57:04 PDT
If the browser wants to open the new page in a tab instead of using a separate window then showing the toplevel windows is not the best idea. How about adding a virtual method QWebPage::showWindow() with a default implentation that shows the toplevel window? I proposed something similar also for the GTK port, see bug #19143.
Simon Hausmann
Comment 5 2008-05-23 01:27:58 PDT
I agree about not calling show() on the QWidget directly. Unfortunately we cannot add virtual functions to QWebPage as it breaks binary compatibility. Fortunately a more consistent API would be to add a signal, similar to menuBarVisibilityChangeRequested or statusBarVisibilityChangeRequested. By default QWebView could connect the signal to its own private slot to call QWidget::show()/hide() accordingly. This way the implementation of ChromeClientQt::show() and FrameLoaderClientQt::dispatchShow() can both be changed to emit the new signal. (In the windows port they also both map to the same call)
Jędrzej Nowacki
Comment 6 2009-11-30 10:00:30 PST
Hi, I tried the issue with this test case on the trunk: <html> <body> <a target="_blank" href="#">blank</a> <a onClick="window.open()">blankJS</a> </body> </html> in both cases a new window was created. It seems that the problem is resolved. I'm not assigned to the bug, so if I missed something feel free to reopen it.
Note You need to log in before you can comment on or make changes to this bug.