Bug 7422 – Setting a frame name to the same value resets it to a generated one

• Status: RESOLVED
• Resolution: FIXED
• Component: Frames

[Jason Levine]

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.)

[Jason Levine]

Created attachment 6670 [details]
test case showing frame name bug

[Jason Levine]

I forgot to mention in my report -- searching through prior bug reports, bug #6751 might be related (or the same).

[Alexey Proskuryakov]

Created attachment 6675 [details]
reduced test case

[Alexey Proskuryakov]

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.

[Jason Levine]

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.

[Alexey Proskuryakov]

Created attachment 6993 [details]
proposed fix

[Darin Adler]

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.