Bug 11756 – REGRESSION: link targeting a frame in another window does not work

• Component: Page Loading
• Status: RESOLVED FIXED

[Giuliano Gavazzi]

a link with a target attribute that targets a frame panel in another window does not perform any action.
See for example: http://www.elfo.org/ it will open a pop-up window (so please do not disable pop-up windows!). The first link in the popup window (and most of the others) are of the form:

<a href="../somepath..." target="testo">some text</a>

where "testo" is the name of the central pane of the main page frame. In the current version of Safari this of course works. I does not in the nightly build of webkit (downloaded today).

Perhaps this is connected with the bug http://bugs.webkit.org/show_bug.cgi?id=10828 ?

[David Kilzer (:ddkilzer)]

*** Bug 14194 has been marked as a duplicate of this bug. ***

[David Kilzer (:ddkilzer)]

This works for me with Safari 3.0 (522.11) and a local debug build of WebKit r23546 on Mac OS X 10.4.9 (8P135).  Giuliano, do you still see this issue?

[Giuliano Gavazzi]

(In reply to comment #2)
> This works for me with Safari 3.0 (522.11) and a local debug build of WebKit
> r23546 on Mac OS X 10.4.9 (8P135).  Giuliano, do you still see this issue?
> 

David,
in webkit r23558 I still see it on http://www.elfo.org/
I have not tried Safari 3.0 yet.
Note that I am on PPC, if that makes any difference.

[David Kilzer (:ddkilzer)]

Confirmed with a local debug build of WebKit r23546 with Safari 3.0 (522.11) on Mac OS X 10.4.9 (8P135).

* STEPS TO REPRODUCE
1. Launch Safari/WebKit.
2. Disable Pop-up Blocking from the "Safari" menu if it is enabled.
3. Go to URL:  http://www.elfo.org/
4. Click in first link in the popped-up window.

* EXPECTED RESULTS
The center frame in the original window (http://www.elfo.org/) should load the new URL.

* ACTUAL RESULTS
Nothing happens.

* REGRESSION
I am unable to test regressions in Safari 2.0.4 (419.3) after installing the 3.0 beta.

* NOTES
This error is printed on the console in Step 3, which may be related to the bug:

ERROR: No parent frame in transitionToCommitted:, FrameLoadTypeInternal
(/path/to/WebKit/WebCore/loader/FrameLoader.cpp:4099 updateHistoryForInternalLoad)

There is also a JavaScript error when loading the main page, but I don't think it's related to this bug (Line 20 is between "-->" and the closing </script> tag?!) :

[3251] http://www.elfo.org/scena/scena.html line 20: TypeError: Undefined value

[David Kilzer (:ddkilzer)]

* REGRESSION
This is a regression since I managed to test the original Safari 2.0.4 (419.3) with the original WebKit.framework, and this works in that version.

Note that this works in Firefox 2.0.0.4 on Mac OS X 10.4.9 (8P135).

In Opera 9.21, the pop-up window never appears even with "Pop-ups" preference set to "Open all pop-ups".

It would be interesting to know what MSIE 6/7 does.

[Giuliano Gavazzi]

On my machine 10.4.9/8P135 (up to SecUpd2007-004Ti included) I do not see the JavaScript console messages in Safari  2.0.4/419.3 and Webkit r23558.
There were two inline css and 1 inline javascript syntax errors according to Opera. I cleared those and now Opera shows the popup.
These corrections do not change the situation with Webkit.

[Giuliano Gavazzi]

(In reply to comment #5)
> It would be interesting to know what MSIE 6/7 does.

looking at the logs I guess that it works fine (the referrer field in the logs is compatible with this). Although the page corresponding to the popup can also be opened in the main frame, I can distinguish this case in the log.

Looking at the logs I noticed that in WebKit the links targeting the main frame simply do not perform any http request to the server. No wonder they do not work..

[David Kilzer (:ddkilzer)]

<rdar://problem/5286420>

[Maxime BRITTO]

I tried to copy the files from the website to my HD and then it was working.
The only thing I modified was the JS call to open the popup : 
before : pippo=window.open("/bacheca/bacheca.html","popup",opt);
after : pippo=window.open("../bacheca/bacheca.html","popup",opt);

I don't really understand how the site can work locally but not remotely...

[Brady Eidson]

"I don't really understand how the site can work locally but not remotely..."

Local files are allowed to access any resource they wish - both local and remote.  There's little security checking on them.

When these pages are on a live, remote server, they are held to a higher security standard.

[Maxime BRITTO]

I have the fix, I'm working now on the test case.

[Maxime BRITTO]

Created attachment 15680 [details]
proposed fix

Here is the fix, there is no attached test case because I'm not very good at these but I'm sure about the fix.
If the test case is essential I can give it another try but I'd prefer to wait for the reviewer opinion.

[Maxime BRITTO]

Created attachment 15682 [details]
test case (needs changes in DRT to work)

This is the test case mitz, bdash and I made but for now it is useless. It will be usefull if the DRT is changed to handle differently the group name of the frames.

[Darin Adler]

Comment on attachment 15680 [details]
proposed fix

r=me

Created attachment 15683 [details]
Allow testing of cross-page frame lookup

Does not regress any existing test.

[Darin Adler]

Please do continue to work on a test case for this. I landed the fix, but we really need a regression test too.

Committed revision 24623.

[Darin Adler]

Comment on attachment 15683 [details]
Allow testing of cross-page frame lookup

r=me

[Giuliano Gavazzi]

(In reply to comment #12)
> Created an attachment (id=15680) [edit]
> proposed fix
> 
> Here is the fix, there is no attached test case because I'm not very good at
> these but I'm sure about the fix.
> If the test case is essential I can give it another try but I'd prefer to wait
> for the reviewer opinion.
> 

thank you for the fix. I have finally tested r25000 with the original site (although it is a non stationary site...) and it works. Will make a couple of static test pages to put on the site and keep an eye of the next releases.
Giuliano

DRT changes and test landed in r25206.