Bug 253708 - with kdewebkit, links pointing to new windows just opens blank tabs
Summary: with kdewebkit, links pointing to new windows just opens blank tabs
Status: RESOLVED FIXED
Alias: None
Product: kwebkitpart
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: unspecified
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: webkit-devel
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-10-09 23:10 UTC by Anders Lund
Modified: 2010-12-12 03:12 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Anders Lund 2010-10-09 23:10:02 UTC
Version:           4.5.2 (using KDE 4.5.1) 
OS:                Linux

Using kdewebkit, links pointing to new windows/tabs will just open a blank tab.
I'm using a setting in konqueror pointing new window => new tab

Fun thing: Using sites where webkit is required for full functionality, AND uses links with target=_blank. So, to open those links rightclick and select "open in new tab".

Reproducible: Always

Steps to Reproduce:
Go to a webpage with links pointing to new windows (target=_blank)
activate view->view mode->webkit
click on a link pointing to a new window

Actual Results:  
a blank tab opens

Expected Results:  
a tab with link contents

OS: Linux (i686) release 2.6.35-ARCH
Compiler: gcc
Comment 1 Dawit Alemayehu 2010-10-19 16:08:01 UTC
Cannot reproduce this issue. Do you have an example site for this ? Clicking on a link that is supposed to open in a new unamed window, i.e. target=_blank works fine here.

Here is a test page for links. Click on the link that says "Open
Comment 2 Anders Lund 2010-10-19 18:24:23 UTC
Here is an example of a page using target=_blank:
http://www.w3schools.com/html/html_links.asp

Scroll down to the target attribute example, and click "try yourself"

Note: This is using kdewebkit inside konqueror, with default user agent (hm, should that change automatically when using kdewebkit??), in kde 4.5.2, using qt 4.7. Konqueror is configured to use new tab instead of new window. The default view is KHTML, so to test you need to activate view->kdewebkit.

ANY link using this (and possibly other new, named targets, dunno) fails, for example clicking in a youtube video to view it at the youtube site. That is an embedded youtube video at the end of this page:
http://minbaad.dk/sejl/archive/2010/17/october/article/myralf-og-hviid-vinder-vm-i-rc44/ - click "youtube" in the lower right corner of the video to get an empty tab - this is actually very annoying, since that URL can not be dragged to the new tab, as with HTML links...
Comment 3 Dawit Alemayehu 2010-10-20 02:00:07 UTC
On Tue, Oct 19, 2010 at 12:24 PM, Anders Lund <anders@alweb.dk> wrote:
> https://bugs.kde.org/show_bug.cgi?id=253708
>
>
>
>
>
> --- Comment #2 from Anders Lund <anders alweb dk>  2010-10-19 18:24:23 ---
> Here is an example of a page using target=_blank:
> http://www.w3schools.com/html/html_links.asp
>
> Scroll down to the target attribute example, and click "try yourself"
>
> Note: This is using kdewebkit inside konqueror, with default user agent (hm,
> should that change automatically when using kdewebkit??), in kde 4.5.2, using
> qt 4.7. Konqueror is configured to use new tab instead of new window. The
> default view is KHTML, so to test you need to activate view->kdewebkit.
>
> ANY link using this (and possibly other new, named targets, dunno) fails, for
> example clicking in a youtube video to view it at the youtube site. That is an
> embedded youtube video at the end of this page:
> http://minbaad.dk/sejl/archive/2010/17/october/article/myralf-og-hviid-vinder-vm-i-rc44/
> - click "youtube" in the lower right corner of the video to get an empty tab -
> this is actually very annoying, since that URL can not be dragged to the new
> tab, as with HTML links...

Ahhh... I now see the problem. It only occurs when you change the
rendering engine using View->Mode->WebKit! Because we do not handle
the case where the newly created part is not a KWebKitPart!

This is simply the same problem and it is a usage issue. I never use
both rendering engines at the same time ; so I do not know how
switching engines using View->Mode behaves. Anyhow, the issue is
simple enough to address ; so it should be fixed shortly....
Comment 4 Dawit Alemayehu 2010-10-20 02:02:10 UTC
SVN commit 1187648 by adawit:

- When a user clicks on a link that opens in a new window/tab, make sure the url is opened
  even when the returned KPart is not a KWebKitPart... 

CCBUG:253708


 M  +9 -1      webpage.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1187648
Comment 5 Dawit Alemayehu 2010-10-21 21:30:52 UTC
Fixed per comment #4 and back ported the fix to the stable kwebkitpart branch as well. See http://websvn.kde.org/branches/stable/extragear-kde4/base/kwebkitpart/
Comment 6 nucleo 2010-11-30 17:01:13 UTC
(In reply to comment #4)
> SVN commit 1187648 by adawit:
> 
> - When a user clicks on a link that opens in a new window/tab, make sure the
> url is opened
>   even when the returned KPart is not a KWebKitPart... 
> 
> CCBUG:253708
> 
> 
>  M  +9 -1      webpage.cpp  
> 
> 
> WebSVN link: http://websvn.kde.org/?view=rev&revision=1187648

Pages are opened in new tab with this fix.
But there is about:blank in address field and if I press on refresh page then blank page will be displayed.
Comment 7 Dawit Alemayehu 2010-12-01 01:20:28 UTC
SVN commit 1202466 by adawit:

- Better workaround for BR# 253708 so that the issue mentioned in comment #6
  of that report is handled properly.
- Set a dynamic QObject property named NavigationTypeUrlEntered whenever openUrl 
  is invoked so that we can distinguish user entered requests from other types.
- Reduced nested if statements whereever possible.
- Enclosed literal text with QLatin1String.

CCBUG:253708


 M  +48 -46    webpage.cpp  
 M  +2 -0      webview.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1202466
Comment 8 Dawit Alemayehu 2010-12-12 03:12:46 UTC
SVN commit 1205667 by adawit:

- Yet more createWindow related changes. Guess spoke too soon on previous commit.
  This implementation is a robust generic fix that handles all window creation
  requests from the browsing engine, i.e. QWebPage::createWindow. 

  Besides dealing with previous bugs such as 253708 and 258367 more appropriately, 
  it also prevents the duplicate creation of a new window if another one with the 
  same name already exists.

CCBUG:253708
CCBUG:258367


 M  +0 -1      CMakeLists.txt  
 D             fakepage.cpp  
 D             fakepage.h  
 M  +171 -127  webpage.cpp  
 M  +36 -0     webpage.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1205667