I'll attach a test case showing the bug, and I've already set up the same test case at the following URL:
(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.)
Created attachment 6670 [details]
test case showing frame name bug
I forgot to mention in my report -- searching through prior bug reports, bug #6751 might be related (or the same).
Created attachment 6675 [details]
reduced test case
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.
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.
Created attachment 6993 [details]
Comment on attachment 6993 [details]
This is fixed in a different way by my patch for bug 3308 -- I'd like to use your layout test but my fix.