307458 - Some pages behave functionally different depending on whether Mozilla's file cache is turned on or off.

Status: RESOLVED INCOMPLETE

(SeaMonkey :: General, defect)

Description

[Kurt Fitzner]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6 (ax)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6 (ax)

I use the SPAW WYSIWYG HTML editor on my web site.  I have found that the editor
behaves differently depending on whether Mozilla's cache is turned on or off.

Reproducible: Always

Steps to Reproduce:
1. Ensure that your cache size is not set to zero.
2. Navigate to http://www.excelcia.org/modules.php?name=Submit_News - you will
see two WYSIWIG HTML editors.
4. Click within the edit area of the top editor.
5. Type some letters.
4. Click witin the edit area of the bottom editor.
6. Type some letters.
7. Turn off your cache by clearing it and setting its size to zero
8. Restart Mozilla/Firefox
9. Repeat steps 2 through 6.

Actual Results:  
Both WYSIWYG editors work (letters typed appear) when the cache is enabled.
Only one WYSIWIG editor (the top one) works when the cache is disabled.

Expected Results:  
Results should be the same, regardless of whether the cache is enabled or not. 
Web pages may reder more slowly without a cache, but there should be no
functional or visual difference after rendering is complete no matter if cache
is enabled or not.

It is unknown whether the bug is caused by enabling or disabling cache.  All
that is known is that Mozilla and Firefox act differently. While the obvious
conclusion is that turning of caching is expressing a bug in Mozilla, it is
equally possible the web page's WYSIWIG editor may be written such that a bug in
rendering that occurs when the cache is ON is what allows it to work as it is
intended.


Firefox (latest devel), and Mozilla 1.8.0.2005070205 were both used to test and
results were identical.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Is this a problem with a current trunk build?  Martijn, if you see this, do you think you can put together a testcase?

Comment 2

[José Jeria]

I can reproduce this with latest trunk build on XP. First time page is loaded the first iframe's desingMode doesnt work. Wait for the to load, and reload and it will work fine. Clear cache and the issue is visible again.

I started doing a minimized testcase and the problem went away when I replaced the iframe:s src to about:blank.

They use a timer (500 ms) to initiate the desginMode. Server is really slow and it could be that the empty.html that is loaded in the iframe hasnt loaded.

Reminds me of bug 207842

Comment 3

[Martijn Wargers (dead)]

I can see the bug also in Mozilla1.7, for me both designMode iframes don't work in that case.
I very much agree with José's analysis. Probably related/duplicate of bug 207842.

Comment 4

[Serge Gautherie (:sgautherie)]

Can you reproduce with SeaMonkey v1.1.9 ?
(or Firefox v2.0.0.14 ?)

Comment 5

[Tony Mechelynck [:tonymec]]

no reply to comment #4 after two years (minus a few days). Resolving INCOMPLETE. Feel free to reopen if still seen, with comment saying in which version of SeaMonkey (2.0.4 or later) or Firefox (3.5.9 or later).