Bug 37847
Summary: | QWebPage::linkClicked() should give an indication of the target frame | ||
---|---|---|---|
Product: | WebKit | Reporter: | Bernhard Rosenkraenzer <bero> |
Component: | WebKit Qt | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED INVALID | ||
Severity: | Enhancement | CC: | hausmann |
Priority: | P3 | Keywords: | Qt, QtTriaged |
Version: | 528+ (Nightly build) | ||
Hardware: | All | ||
OS: | All |
Bernhard Rosenkraenzer
There's currently no way (or at least no obvious way) for a QWebView that needs customized handling of links to see the target frame of a link. It would be good if QWebPage::linkClicked() provided both the clicked url and the link's target frame, or maybe even the QWebHitTestResult that caused linkClicked() to be triggered.
Attachments | ||
---|---|---|
Add attachment proposed patch, testcase, etc. |
Simon Hausmann
Indeed, linkClicked() doesn't provide this functionality. But you can easily get the information you're looking for by re-implementing QWebPage::acceptNavigationRequest. Its default implementatino is the place where linkClicked() is emitted from. This function has the target QWebFrame as a parameter.
Bernhard Rosenkraenzer
Right... but it would IMO be better to just change lines 2376 and 2380 of qwebpage.cpp to emit linkClicked(request.url(), frame); [once changing the ABI is ok, so probably not before Qt5] -- the information is rather relevant, and having to overload QWebPage to access it is not a very convenient way to get it (also implies having to setPage() on any QWebView).
Simon Hausmann
Fair enough, we could overload linkClicked() I think.
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.
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.