312027 - Firefox 1.5b2: HTML Validator extension hangs when trying to read cached page during pageShow event if page has inline script that redirects

Status: RESOLVED WORKSFORME

(Firefox :: General, defect)

Description

[mgueury]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b5) Gecko/20051001 Firefox/1.4.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b5) Gecko/20051001 Firefox/1.4.1

The extension HTML Validator based on Tidy hangs with Firefox 1.5 B2 after
having enabled the BF Cache trigger.

(I am the extension author)

The extension home page is this if you want some info:
> http://users.skynet.be/mgueury/mozilla/index.html


Reproducible: Always

Steps to Reproduce:
1. Download the HTML validator 0.73 (with the issue) in Firefox 1.5 b2
  windows: http://htmlvalidator.sourceforge.net/mozilla/tidy_firefox_win_073.xpi
  linux: http://htmlvalidator.sourceforge.net/mozilla/tidy_firefox_linux_073.xpi
2. Restart Firefox, check the validation works by going to www.google.com for
   example.
3. go here:
   > http://remik.org/test.html
   Press OK.
   It hangs in the BF cache pageShow trigger during reading of the HTML cache
   of the browser. This is the bug. 

Actual Results:  
The problem is this: 
- In Firefox 1.5 B2, the LOAD trigger is not fired when an user do a back or
  forward in the browser. This is described here: 
  > http://developer.mozilla.org/en/docs/Using_Firefox_1.5_caching
- So, I followed this document and added the trigger "pageShow".
- It works in most case except when the page contains an onload trigger doing a 
  redirect, like this :

----------------------------------------------------------------------
<script type="text/javascript">
    alert("click ok!");
    document.location.href="http://mozilla.org";
</script>
----------------------------------------------------------------------

In such case, 
- in place that the LOAD trigger is fired when rendering the page
- the pageShow trigger is fired first
- then the program tries to read the HTML from the cache of the page 
  to validate it, but Firefox hangs.

My problem is that I am not able to fix it.
1) If I disable the BF cache trigger (pageShow). It does not hang anymore 
   but I am not able to detect the back and forward change in the browser.
   The result is that the icon does not change when the user do a back or
   forward in the history

2) If I enable it, back and forward validation works. But it hangs in the 
   case above. My concern is that I am unable to distinguish between a back 
   or forward and a potential hanging situation.


Expected Results:  
Not hang. For ex, give an exception so that I can handle it.

Any idea or work-around to fix it is welcome.
And/or a fix in the Firefox code that cause the hanging.

Thanks by advance

Marc

Comment 1

[Scott MacGregor]

is it possible the patch in 309581 gives you the event you are looking for here?

Comment 2

[mgueury]

My issue is happening in the pageshow trigger when using a nsIChannel and some
flags to get the HTML from the cache. You can see the way I do this, here:

http://cvs.sourceforge.net/viewcvs.py/htmlvalidator/validator/tidy_extension/jar/content/tidyBrowser.js?rev=1.4&view=markup
Look for "getHtmlFromCache : function( doc, safe_call )"

It is a pageShow issue and not a pageHide one like the other bug.

In the meanwhile, I think I found a work-around to this issue by not calling
this getHtmlFromCache at all in pageshow. I will cache the validation 
result  in each document javascript structure. So that when doing back and
forward, I will just display the result from the original validation.

I need to test this further.

Comment 3

[mgueury]

I wrote the wa I wa thinking of and it seems to work. I mailed the persons
who reported the issue and they seems to be happy with the new version (0.74)

I must say I am a little worry about it since the same code would not
work in Firefox 1.0.7. If I put some javascript data as a member of a document
after about 10 sec, it is most of the time gone for an unknown reason.

Here the good news is that it seems to work fine. When I do a back, 
even some minutes after the javascript data is still in the document and 
I can display the stored validation result without problem. 

I hope that there is no loss of the javasript document structure after 
a while or when the history is too big. Else the wa will not fully work...

Can you answer to this concern ? Does the full history of the HTML pages
stays in the BF cache or is it purged after a while or when it reach
a certain amount of memory ?

Thanks by advance

Comment 4

[Serge Gautherie (:sgautherie)]

Marc, what about this bug nowadays ?
(with Firefox v2/v3 + HTML Validator v0.7.9.5/v0.8.4.4)

Comment 5

[mgueury]

Hi Serge,

Due that the extension work-around the issue since version 0.74, there is no real problem anymore about this now. 

Comment 6

[Serge Gautherie (:sgautherie)]

(In reply to comment #0)
>    > http://remik.org/test.html

(This domain doesn't exist anymore.)
Could you update the bug URL ?

(In reply to comment #2)
> http://cvs.sourceforge.net/viewcvs.py/htmlvalidator/validator/tidy_extension/jar/content/tidyBrowser.js?rev=1.4&view=markup

This domain doesn't exist anymore either...

(In reply to comment #3)
> Can you answer to this concern ? Does the full history of the HTML pages
> stays in the BF cache or is it purged after a while or when it reach
> a certain amount of memory ?

Do the |browser.sessionhistory.*| settings
at <http://kb.mozillazine.org/About:config_entries>
answer your question ?

(In reply to comment #5)
> Due that the extension work-around the issue since version 0.74, there is no
> real problem anymore about this now. 

<http://users.skynet.be/mgueury/mozilla/release_note.html>
{{
2005-OCT-12
Current version : 0.74
- Implemented a bad work-around for Firefox 1.5b2 BF cache hanging bug:
   https://bugzilla.mozilla.org/show_bug.cgi?id=312027
}}
This, I understood from your comment 3.

What I'm trying to find out is whether this was/is a bug in your extension or in Firefox.
In the latter, I'd like to know if this was actually specific to FF v1.5b2 (so you could remove your workaround now), or if the bug is still present in the current code(s) (and should probably be fixed).

Comment 7

[Tyler Downer [He/Him]]

This bug is part of a query for Firefox bugs that have Status set to NEW, but have version field set to 2.0 or older and have not changed in over 800 days.

http://tiny.cc/forgottennewbugs

If you still see this bug, or if it is still valid with Firefox 3.6.10 or a firefox 4 nightly build, please update the version field and steps to reproduce.

Comment 8

[Matthias Versen [:Matti]]

no response to Tyler's question