[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

()

Core
Security
P1
major
VERIFIED FIXED
12 years ago
12 years ago

People

(Reporter: Carlos Cestero, Assigned: bz)

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

Updated

12 years ago
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.