[FIX]Different-domain subframe can't document.write/document.open to itself (DHTML Menu does not display when using masked domains)

VERIFIED FIXED in mozilla1.9alpha1

Status

()

P1
major
VERIFIED FIXED
12 years ago
12 years ago

People

(Reporter: support, Assigned: bzbarsky)

Tracking

({regression, verified1.8.0.10, verified1.8.1.2})

Trunk
mozilla1.9alpha1
regression, verified1.8.0.10, verified1.8.1.2
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.8.1.2 +
blocking1.8.0.10 +
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(3 attachments)

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.7) Gecko/20060913 Fedora/1.5.0.7-1.fc5 Firefox/1.5.0.7 pango-text
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.7) Gecko/20060913 Fedora/1.5.0.7-1.fc5 Firefox/1.5.0.7 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.
(Reporter)

Updated

12 years ago
Version: unspecified → 2.0 Branch
(Reporter)

Updated

12 years ago
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
Blocks: 343168
Component: Menus → Security
Product: Firefox → Core
QA Contact: menus → toolkit
Version: 2.0 Branch → Trunk
Created attachment 247550 [details]
Subframe for testcase
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.
Attachment #247552 - Flags: superreview?(jst)
Attachment #247552 - Flags: review?(jst)
(Assignee)

Updated

12 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.8.1.2?
Flags: blocking1.8.1.1?
Flags: blocking1.8.0.9?
Flags: blocking1.8.0.10?
Keywords: regression
Comment on attachment 247552 [details] [diff] [review]
Patch.

Looks good. r+sr=jst
Attachment #247552 - Flags: superreview?(jst)
Attachment #247552 - Flags: superreview+
Attachment #247552 - Flags: review?(jst)
Attachment #247552 - Flags: review+
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...
Attachment #247552 - Flags: approval1.8.1.1?
Attachment #247552 - Flags: approval1.8.0.10?
Fixed on trunk.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
Need support for multiple domains in mochitest to add a test...
Flags: in-testsuite?
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 1.8.0.8 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...
Attachment #247552 - Flags: review?(mrbkap) → review+
Flags: blocking1.8.1.1?
Flags: blocking1.8.0.9?
Flags: blocking1.8.1.2?
Flags: blocking1.8.1.2+
Flags: blocking1.8.0.10?
Flags: blocking1.8.0.10+
Comment on attachment 247552 [details] [diff] [review]
Patch.

approved for 1.8/1.8.0 branches, a=dveditz for drivers
Attachment #247552 - Flags: approval1.8.1.1?
Attachment #247552 - Flags: approval1.8.1.1+
Attachment #247552 - Flags: approval1.8.0.10?
Attachment #247552 - Flags: approval1.8.0.10+
Attachment #247552 - Flags: approval1.8.1.1+ → approval1.8.1.2+
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: fixed1.8.0.10, fixed1.8.1.2
Verified fixed for 1.8.1.2. and 1.8.0.10 with Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.0.10pre) Gecko/20070108 Firefox/1.5.0.10pre
Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.1.2pre) Gecko/20070108 BonEcho/2.0.0.2pre for Windows and also on Fedora FC 6
Status: RESOLVED → VERIFIED
Keywords: fixed1.8.0.10, fixed1.8.1.2 → verified1.8.0.10, verified1.8.1.2
You need to log in before you can comment on or make changes to this bug.