WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
7422
Setting a frame name to the same value resets it to a generated one
https://bugs.webkit.org/show_bug.cgi?id=7422
Summary
Setting a frame name to the same value resets it to a generated one
Jason Levine
Reported
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.)
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
View All
Add attachment
proposed patch, testcase, etc.
Jason Levine
Comment 1
2006-02-22 12:31:44 PST
Created
attachment 6670
[details]
test case showing frame name bug
Jason Levine
Comment 2
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).
Alexey Proskuryakov
Comment 3
2006-02-23 02:01:00 PST
Created
attachment 6675
[details]
reduced test case
Alexey Proskuryakov
Comment 4
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.
Jason Levine
Comment 5
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.
Alexey Proskuryakov
Comment 6
2006-03-10 11:50:49 PST
Created
attachment 6993
[details]
proposed fix
Darin Adler
Comment 7
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.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug