Confirming report with Mozilla trunk binary 2003033105 WinNT. This is either for the DOM or Security, not JS Engine. Reassigning to Security for further triage -
Assignee: rogerl → mstoltz
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: pschwartau → carosendahl
confirmed with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030422 even worse: for me it seems not only related to cross-domain links. I get the error in the HTML Client of our Content Management System (VIP 8 by http://www.gaussvip.com). All pages of this application reside on one server, all have same domain and nevertheless: on some pages,when a script in one frame tries to change the location of another frame it does nothing. Strangely it does not happen on all cross frame actions, only on some. I tried to debug this using Venkman but the stuff is way to complex for me to unerstand what's going on. Everything works fine when using Moz 1.3.1 or below
> As an example, see http://textz.com/index.php3?section=concept (frameset: > textz.com, frames: textz.gnutenberg.net). this example worksforme (moz 1.8 nightly) > The same is true for subdomains. Go to > http://lists.minordomo.org/textz.com/index.php and click 'moderate' the site suffers serious usability issues. Please give the direct link to "moderate" add qawanted keyword. Reporter (rolux), can you give us a reduced testcase?
worksforme moz 1.7.3, worksforme firefox 1.0, and per comment4, worksforme 1.8 nightlies no response from reporter -> wfm
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → WORKSFORME
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1pre) Gecko/20090526 Shiretoko/3.5pre I'm trying to come up with a minimized test case for this (old) bug. 1. Download both files to the same location 2. Open frameset.html in the browser 3. Click the Test link RESULT: 1. Google on top, test page on the bottom 2. Digg on top, test page on bottom after link click 3. Exception in Error Console: Error: Permission denied for <http://view.atdmt.com> to call method Location.toString on <file://>. I'm not sure if this is related to this bug or not. Please advise me on both my test case and the result.
Verifying WORKSFORME due to lack of feedback and inability to reproduce.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.