User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040807 Mnenhy/0.6.0.100 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040807 Mnenhy/0.6.0.100 When viewing http://www.filmz.de/film_2004/hidalgo_3000_meilen_zum_ruhm/links.htm, then opening http://www.movie.de/movie_start.php?id=170 in the same window and pressing back mozilla crashes Reproducible: Always Steps to Reproduce: 1. Open http://www.filmz.de/film_2004/hidalgo_3000_meilen_zum_ruhm/links.htm in a window 2. Open http://www.movie.de/movie_start.php?id=170 in the same window 3. Press the back buttom or press Alt-Left Actual Results: Mozilla crashes Expected Results: show again the first site This bug was not present on 2004-08-07, but was present on 2004-08-12 (up to today 2004-08-18) on the CVS.

Can you please post a Talkback ID from that crash ?

(In reply to comment #1) > Can you please post a Talkback ID from that crash ? I don't know anything about Talkback ID's. How can I get one?

Same happened with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040817

Generalization: The bug happens when visiting the first page and visiting another link on this domain, e.g. klicking on "Kommentare". Or visiting every other domain's website in this window and going back. It seems that the bug has something to do with the layout (CSS?) of all pages on the first webpages domain.

Regression window is 2004-08-11-05 -- 2004-08-12-07, where bug 255153 seems the most likely culprit.

After backing out bug 255153 I cannot reproduce the crash.

WFM with Mozilla 2004081709 on WinNT4. (In reply to comment #3) > I don't know anything about Talkback ID's. How can I get one? see for example bug 254107 comment 2

(In reply to comment #8) > > I don't know anything about Talkback ID's. How can I get one? > see for example bug 254107 comment 2 This talkback.xpi goes not to the user profile. :-( Hope, the backtrace of Mats is ok.

Hmm.. Chances are, we're reentering frame construction because someone tries to get the primary frame while in frame construction, which causes a restyle flush... Does it help if we change the frame constructor to flush restyles before starting in on constructing new frames? Note that I'm not going to be able to usefully work on this till at least September 9th.

I would like to change OS from 'Linux' to to 'All', because I can reproduce this crasher fine with: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a3) Gecko/20040818 Mnenhy/0.6.0.104 {Build ID: 2004081808} Send an Talkback-Report: TB593608K -- Notice that the Talkbackserver is a bit late this time, might take a while till its there.

Or better yet, does it help if we fix the presshell to flush restyles on the frame constructor before doing the Content* callbacks to it?

I can't reproduce this one in a vanilla debug build from yesterday....

> I can't reproduce this one in a vanilla debug build from yesterday.... Same to me. I contacted the author of the pages, if he had changed something. His answer: In German: "Was aber das Script angeht, gibt es nur eine Änderung: Ich habe den Zeitpunkt des Funktionsaufrufs zur Positionierung und Sichtbarmachung der iframes (Seitenflügel) etwas nach vorne verlegt. Vorher: onload nach Laden des Hintergrundbildes in den Seitenflügeln, jetzt schon während des Ladens der /i/l.htm bzw. /i/r.htm (als <SCRIPT> im Quelltext)." Translated: "There is only one change in the script: I brought forward the moment of calling the function to place and make visible the iframes (the side wings). Before: onload after loading the background picture in the side wings. Now: already on loading of /i/l.htm resp. /i/r.htm as <SCRIPT>." Maybe this changes did the point.

Yes, that change could very well have affected this crash.. If someone can create a testcase that has that change undone and crashes that would be incredibly helpful....

Here is a HTML document which crashes Mozilla (CSV build from 2004-09-11) even when visiting: http://www.filmz.de/film_2004/hidalgo/links.htm It's the old version of the original site.

The author of the site wrote to me, that he has another suspicion: In the original side wings there was the (shortened) code: this.frameElement.style.left=parent.innerWidth/2-392; Now it is: this.frameElement.style.left=Math.floor(parent.innerWidth/2)-392; Maybe there are problems in floating point numbers.

> http://www.filmz.de/film_2004/hidalgo/links.htm I can't reproduce the crash here either. And no, there is no problem with floating point numbers. I just checked in some fixes that would help fix crashes of this type. Could someone who can reproduce this crash please retest in tomorrow's builds?

(In reply to comment #18) > I can't reproduce the crash here either. Very, very strange. Yesterday I tried it two times, and (a current) mozilla crashed (even when visiting). But now neither a current nor an older mozilla will crash on this demo site (even when clicking around and pressing back). I'll contact the author again...

(In reply to my comment #19) > I'll contact the author again... He wrote me that this page has no differences to the crash version. He now adjusted the HTTP-EQUIV="Expires" header from <META HTTP-EQUIV="Expires" CONTENT="Wed, 25 Aug 2004 22:00:00 GMT"> to <META HTTP-EQUIV="Expires" CONTENT="Wed, 24 Nov 2004 22:00:00 GMT"> And he changed back the banner to the one which was supposably there at bug report time. But he does not think that the banner may be the cause. Unfortunately I can't reproduce the crash no more (with no mozilla version, both with clearing my cache completely). So what to do with this bug report?

The cause was a script of some sort (I dunno whether the banner is a script or not). If no one can reproduce the bug and we can't figure out how to get it to happen, we mark it worksforme, I guess... This is why it's best to attach a testcase to the bug itself (nonminimal if needed) in case the page gets changed.

Think this would be the best. May you attach the URL http://www.filmz.de/film_2004/hidalgo/links.htm as testcase? I don't see a way to add an URL, but only (local) files. Note: The URL includes other .htm pages.

The best way to handle that sort of thing is to save the page as "web page, complete" and then see whether the saved version shows the bug... if it does, zip up all the files and attach the zip to the bug report.

(In reply to comment #23) > and then see whether the saved version shows the bug... if it does, But it doesn't. So no testcase attachment and WORKSFORME. :wq

WFM, 2004-09-13-06 trunk Linux