User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-AR; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-AR; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9 When dynamically generated html documents (using live connect - JSObject) are refreshed, they loose the styles. If the applet is running in a local filesystem the html document is shown like plain text (no styles, and links are not shown, just looks like plain text). However, if you see the source code, it's ok, but that is not what you see. Reproducible: Always Steps to Reproduce: 1. Go to the provided url (it's in Spanish, English, and French) 2. Make sure you have the latest java plugin: in the provided URL there is a link to get it. Only if you can't see the applets working... When ready open the error console and clean it (Yahoo! made the errors!) 3. Type a keyword to search in the textbox on the left frame (suggested: chapala). Click Buscar/Search according to your language 4. The central frame (the one in black background) will display a dynamically generated document with the search results and links to the pages (9). This document is shown with some styles (linked to a css file). You can see the source code of the frame and save it to use it later. The error console is still clean. 5. Click on any link of the search results. The central frame will go to the linked page (it's a normal html document, no Live Connection here). The error console is still clean. And then Click back on firefox to return to the search results. Or alternatively, refresh the results frame. See what happens: Actual Results: The styles on the search results have gone!. See the source code of the frame and compare it to the previously saved: it's the same. HOWEVER, there are 2 warnings in the error console now: 1.Unexpected end of file looking for '',' or '{''. Ruleset ignored due to bad selector. Source: http://geocities.com/neutron3210/lerma-chapala/Styles.css line: 1 Unexpected end of file looking for 'closing } of invalid rule set'. Source: http://geocities.com/neutron3210/lerma-chapala/Styles.css line: 1 This is the contents of the css file (which is used in the whole site) a:link {font: 10pt/12pt verdana; color:#777777} a:visited {font: 10pt/12pt verdana; color:#AF0000} h1 {font: 18pt/20pt verdana; color:#8080FF} h2 {font: 8pt verdana; color:#999999; background:#000000} table {font: 8pt/11pt verdana; color:#AAAAAA; border-spacing:0;} td {font: 8pt/11pt verdana; color:#AAAAAA; padding:2} th {font: 8pt/11pt verdana; color:#FFFFFF; padding:5} body, p {font: 10pt verdana; color:#FFFFFF; background:#000000; text-align:justify;} Expected Results: The search results dynamically created web page should be shown always as it was made. This maybe a conflict with 387333 bug, since we try to access wyciwyg:// documents. If the web site is tested in my local machine then the documents are local and in this case not only the styles are gone, but all the format - links appear like plain text. However, dynamic source code still is right.

This doesn't happen in IE6, nor in older versions of Netscape (don't know in newer, since I moved to firefox!). If you can't see the source URL, it is: http://geocities.com/neutron3210/lerma-chapala/index.html

bug 387333 was fixed in Firefox 2.0.0.5, I see this same behavior on your site going back to at least Firefox 1.5(.0.0). It's definitely not due to bug 387333.

Could use a regression range (assuming it's a regression at all)...

This was once a problem on trunk too, but it was fixed by bug 255820. http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=1178678820&maxdate=1178680139

Oh. This page is using document.write. OK, then. Thank you, Ria!

(In reply to comment #5) > Oh. This page is using document.write. OK, then. Thank you, Ria! > > *** This bug has been marked as a duplicate of bug 255820 *** > Hey, Boris: I don't agree it's the same case: I don't use the: <META http-equiv=Content-Type content="text/html; charset=us- ascii"> tag... It's only pure html - special chars are printed using &***; html codes. Unless that omitting the meta tag makes the browser set any kind of default!

This is a sample of the dynamically generated document: (no meta used!) And also, the first time styles ARE applied... only when refreshing they dissapear! <html> <head> <link rel=STYLESHEET class=text/css href=Styles.css> </head> <body> <hr><h1>Resultados encontrados:</h1> (9: chapala) <br>1. <A HREF=PagES.html#1>Datos Generales</A><br> ... </body> </html>

I have no branch nightly builds so I can't test them, but before Firefox 2.0.0.1 the site was already broken. This is regression window on trunk: http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=2005-08-19+06%3A00&maxdate=2005-08-19+21%3A00 I did only random checks (one every half year).

What is a regression window? the access to previous versions? And anyway, if it was already broken for several previous versions, is it a bug of firefox or something wrong in my code? (again, in IE5-6 and netscape it works fine!)

> Unless that omitting the meta tag makes the browser set any kind of default! Precisely. The default is ISO-8859-1. The duplicate resolution is correct. Please don't mess with it again, ok? The trunk regression range corresponds to bfcache being turned off for subframes, which would make us actually hit the case in bug 255820. > is it a bug of firefox Yes. The fix will be in Firefox 3.