User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:18.104.22.168) Gecko/20060913 Fedora/22.214.171.124-1.fc5 Firefox/126.96.36.199 pango-text Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:188.8.131.52) Gecko/20060913 Fedora/184.108.40.206-1.fc5 Firefox/220.127.116.11 pango-text Okay... I have found a big problem with Firefox 2... (I will try to explain it the best I can) This is my webpage: http://tekunixcorp.com The domain is registered thru godaddy.com...now... that domain (tekunixcorp.com) is pointing to http://netdial.caribe.net/~tekunix/store.htm The problem is that when using Firefox 2 and you go to tekunixcorp.com you will not see the DHTML menu on the top (you will see the image "menu loading"... now... if you go directly to netdial.caribe.net/~tekunix/store.htm you will be able to see the menu, using the same browser. So, basically there is a problem with the "cloak or masking". Firefox 2 is unable to make the forward and display the page correctly. The page works perfectly with IE 6, 7 and Firefox 1.5. The problem is only with Firefox 2. Also the problem is not godaddy with the forward because I also have tekunix.com registered with DynDNS and the problem is the same. Another example: http://tekunix.com/en.html (menu does NOT work) http://g2k.serveftp.net/en.html or http://netdial.caribe.net/~tekunix/en.html (menu works) Firefox 2 is unable to make the forward correctly and be able to display the DHTML menu. If someone from firefox can help me... it would be great... thank you. Reproducible: Always Steps to Reproduce: 1.http://tekunix.com/en.html (menu does NOT work) 2.http://g2k.serveftp.net/en.html or http://netdial.caribe.net/~tekunix/en.html (menu works) 3.that's it... Actual Results: DHTML menu not showing. Expected Results: DHTML menu displayed. Well... as I mention... it doen't work with godaddy & dyndns forwards...so I guess it will not work with any domain forward...and I selected only xp and pc above... but I think it should happen with any platform an OS... it's just Firefox 2.
Summary: DHTML Menu does not display when using redirected domains... → DHTML Menu does not display when using masked domains...
I get this js error in the error console: Error: uncaught exception: [Exception... "Security error" code: "1000" nsresult: "0x805303e8 (NS_ERROR_DOM_SECURITY_ERR)" location: "<unknown>"] This regressed on 1.8.1 branch between 2006-08-10 and 2006-08-12: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=MOZILLA_1_8_BRANCH&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-08-10+04&maxdate=2006-08-12+07&cvsroot=%2Fcvsroot I guess this is somehow a regression from bug 343168, but that patch also went into the 1.8.0.x branch, where it doesn't cause this problem.
Assignee: nobody → dveditz
Component: Menus → Security
Product: Firefox → Core
QA Contact: menus → toolkit
Version: 2.0 Branch → Trunk
Created attachment 247551 [details] Testcase So the problem is that we're not allowing a document to touch itself. The "redirection" stuff in comment 0 is a red herring; http://tekunix.com/en.html is just a frameset that frames a different site.
Well, you may have to save that testcase and edit the url a bit, since bug 332179 was apparently not fixed correctly...
Created attachment 247552 [details] [diff] [review] Patch.
12 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment on attachment 247552 [details] [diff] [review] Patch. Looks good. r+sr=jst
See bug 343168 comment 18 for why this is not a problem with 1.8.0 builds.
Assignee: dveditz → bzbarsky
OS: Windows XP → All
Priority: -- → P1
Hardware: PC → All
Summary: DHTML Menu does not display when using masked domains... → [FIX]Different-domain subframe can't document.write/document.open to itself (DHTML Menu does not display when using masked domains)
Target Milestone: --- → mozilla1.9alpha
Comment on attachment 247552 [details] [diff] [review] Patch. We should take this for 1.8 ASAP, and for 1.8.0 once bug 343168 comment 18 is resolved...
Fixed on trunk.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
Need support for multiple domains in mochitest to add a test...
Comment on attachment 247552 [details] [diff] [review] Patch. We've already got candidate builds and this regression doesn't seem like a stop-ship bug. Am I missing something? (especially given we don't have a lot of dupes for this problem and FF2 has been out for a month.) I'll leave this nominated anyway as a potential ride-along candidate if we need to respin. I'd like mrbkap to look at this, and especially to consider what needs to be done with bug 343168 comment 20 and 18. I note that 18.104.22.168 fails the testcase in this bug though, even though it apparently works on the real-life site.
Attachment #247552 - Flags: review?(mrbkap)
Yeah, I wrote this testcase before I noticed the difference with 1.8.0. ;) I agree that this shouldn't necessarily block the release if we shipped it in FF 2.0...
Comment on attachment 247552 [details] [diff] [review] Patch. approved for 1.8/1.8.0 branches, a=dveditz for drivers
Attachment #247552 - Flags: approval22.214.171.124+ → approval126.96.36.199+
Need to resolve the issue with 1.8 vs 1.8.0; I'm not happy checking this in until that happens. I filed bug 364309 on sorting it out.
Depends on: 364309
Fixed on both branches.
Keywords: fixed188.8.131.52, fixed184.108.40.206
Verified fixed for 220.127.116.11. and 18.104.22.168 with Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:22.214.171.124pre) Gecko/20070108 Firefox/126.96.36.199pre Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:188.8.131.52pre) Gecko/20070108 BonEcho/184.108.40.206pre for Windows and also on Fedora FC 6
Status: RESOLVED → VERIFIED
Keywords: fixed220.127.116.11, fixed18.104.22.168 → verified22.214.171.124, verified126.96.36.199
You need to log in before you can comment on or make changes to this bug.