Bug 19077

Summary:

[Qt] Clicking on a link with target=_blank doesn't do anything

Product:

WebKit

Reporter:

Marco Barisione <marco.barisione>

Component:

Platform

Assignee:

Marco Barisione <marco.barisione>

Status:

RESOLVED FIXED

Severity:

Normal

CC:

hausmann, jedrzej.nowacki

Priority:

Keywords:

Version:

528+ (Nightly build)

Hardware:

All

OS:

All

Attachments:

Description	Flags
Show the window containing the newly created QWebPage	hausmann: review-

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-	Details Formatted Diff Diff
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.