Bug 7422 - Setting a frame name to the same value resets it to a generated one
Summary: Setting a frame name to the same value resets it to a generated one
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Frames (show other bugs)
Version: 420+
Hardware: Macintosh OS X 10.4
: P2 Normal
Assignee: Darin Adler
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-02-22 12:30 PST by Jason Levine
Modified: 2006-03-10 19:16 PST (History)
1 user (show)

See Also:


Attachments
test case showing frame name bug (3.08 KB, application/zip)
2006-02-22 12:31 PST, Jason Levine
no flags Details
reduced test case (755 bytes, text/html)
2006-02-23 02:01 PST, Alexey Proskuryakov
no flags Details
proposed fix (2.21 KB, patch)
2006-03-10 11:50 PST, Alexey Proskuryakov
darin: review-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jason Levine 2006-02-22 12:30:57 PST
It appears that one cannot set the name of a frame using Javascript in Safari (both 417.8 and the latest nightly build, r12930); trying to do so results in the frame getting a name that appears to be some sort of underlying code comment ("<!--framePath //<!--frame2-->-->").

I'll attach a test case showing the bug, and I've already set up the same test case at the following URL:

http://jzone.queso.org/safariframes/

(I ran into this bug for the first time yesterday, when the latest release candidate of phpMyAdmin was released and broke; it relies on being able to set the main content frame's name in order to target links appropriately, and now they are all opening in new windows as a result!  Because of the popularity of phpMyAdmin, I've set the severity of the bug to major -- apologies in advance if this was presumptive of me.)
Comment 1 Jason Levine 2006-02-22 12:31:44 PST
Created attachment 6670 [details]
test case showing frame name bug
Comment 2 Jason Levine 2006-02-22 12:34:19 PST
I forgot to mention in my report -- searching through prior bug reports, bug #6751 might be related (or the same).
Comment 3 Alexey Proskuryakov 2006-02-23 02:01:00 PST
Created attachment 6675 [details]
reduced test case
Comment 4 Alexey Proskuryakov 2006-02-23 02:12:33 PST
Setting the frame name normally works, but if the new name is already taken, a generated one is used instead, to avoid duplicate names. Here, a frame named 'frame_content' is renamed to 'frame_content', thus renaming fails.

Working around the problem should be trivial: just don't try to set the frame name if it's already correct. So, I'm downgrading the severity to normal (though setting it to major originally was perfectly fine IMO).

This special case can be easily fixed in WebCore; however, the general problem of exposing generated names is not clear to me.
Comment 5 Jason Levine 2006-02-23 06:59:26 PST
Thanks for the clarification, Alexey -- I hadn't thought forward enough to test whether it was a universal issue (setting ANY frame's name, regardless of what the frame's current name is).  It turns out that 90+ percent of the time, phpMyAdmin is trying to set the name of the frame when it's already the right thing, hence me seeing the bug there... and you're right, wrapping the attempt in an if statement testing the frame's current name works around the problem.
Comment 6 Alexey Proskuryakov 2006-03-10 11:50:49 PST
Created attachment 6993 [details]
proposed fix
Comment 7 Darin Adler 2006-03-10 14:53:32 PST
Comment on attachment 6993 [details]
proposed fix

This is fixed in a different way by my patch for bug 3308 -- I'd like to use your layout test but my fix.