Bug 91779 – [Qt] Implement open new window policy action.

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

[Alexis Menard (darktears)]

[Qt] Implement open new window policy action.

[Alexis Menard (darktears)]

Created attachment 153327 [details]
Patch

[Alexis Menard (darktears)]

(In reply to comment #1)
> Created an attachment (id=153327) [details]
> Patch

Very simple for now.

[Simon Hausmann]

Comment on attachment 153327 [details]
Patch

I'd rather not have this in the public for the initial release, because I think it's likely that we will regret it. We know already that it's insufficient to covert use-cases like form posting, JS window.close() after window.open(), etc.

I think a better API would be one that allows properly cloning, i.e. something like in qtdeclarative/examples/window/Window.qml

What do you think?

[Alexis Menard (darktears)]

(In reply to comment #3)
> (From update of attachment 153327 [details])
> I'd rather not have this in the public for the initial release, because I think it's likely that we will regret it. We know already that it's insufficient to covert use-cases like form posting, JS window.close() after window.open(), etc.
> 

Ok with that, I can put it experimental.

> I think a better API would be one that allows properly cloning, i.e. something like in qtdeclarative/examples/window/Window.qml
> 
> What do you think?

I fail to see the difference unless I didn't get this "cloning" thingy concept. What would be the benefits?

[Alexis Menard (darktears)]

(In reply to comment #4)
> (In reply to comment #3)
> > (From update of attachment 153327 [details] [details])
> > I'd rather not have this in the public for the initial release, because I think it's likely that we will regret it. We know already that it's insufficient to covert use-cases like form posting, JS window.close() after window.open(), etc.
> > 
> 
> Ok with that, I can put it experimental.
> 
> > I think a better API would be one that allows properly cloning, i.e. something like in qtdeclarative/examples/window/Window.qml
> > 
> > What do you think?
> 
> I fail to see the difference unless I didn't get this "cloning" thingy concept. What would be the benefits?


I was trying to at least cover the <a target="_blank"> case.

[Simon Hausmann]

(In reply to comment #4)
> > I think a better API would be one that allows properly cloning, i.e. something like in qtdeclarative/examples/window/Window.qml
> > 
> > What do you think?
> 
> I fail to see the difference unless I didn't get this "cloning" thingy concept. What would be the benefits?

Instead of having a signal that you _react_ to - by creating a new view and passing along signal parameters, the cloning approach requires you to specify a component up-front, but then you don't have to react anymore and instead WebKit can create a view when it needs to, with full access.

It allows for JS like this to actually work:

    var view = window.open("", "", "width=100, height=100")
    view.document.writeln("<p>Hello world");
    view.focus();
    ...
    // and much later somewhere else
    view.close();


That is why in WK1 we had virtual QWebPage* QWebPage::createWindow(); that solves the target=_blank easily as well as more complex use-cases like above.

[Simon Hausmann]

Comment on attachment 153327 [details]
Patch

I'm taking this out of the review queue. I'm not sure it's the right approach and I don't think the signal should go into the public section right away.

[Sergejs Kovrovs]

(In reply to comment #7)
> (From update of attachment 153327 [details])
> I'm taking this out of the review queue. I'm not sure it's the right approach and I don't think the signal should go into the public section right away.

If `navigationRequested` is part of public API I see no reason why there is no `openNewWindowRequested`.

This issue blocking migration to Qt 5.0.

[Jocelyn Turcotte]

=== Bulk closing of Qt bugs ===

If you believe that this bug report is still relevant for a non-Qt port of webkit.org, please re-open it and remove [Qt] from the summary.

If you believe that this is still an important QtWebKit bug, please fill a new report at https://bugreports.qt-project.org and add a link to this issue. See http://qt-project.org/wiki/ReportingBugsInQt for additional guidelines.