Closed Bug 420025 Opened 16 years ago Closed 8 years ago

contentDocument not populated after pageshow event

Categories

(Core :: General, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: themystic.ca, Unassigned)

References

Details

Attachments

(6 files)

On some webpages contentDocument is not populated properly even after pageshow has fired. 

I'm attaching an extension which provides a button to trigger this bug as well as two saved webpages (of cvmarket.lt and haaretz.com) which have to be used in conjunction with the extension.

It should be noted that this bug can be triggered on Firefox 2.0.0.12 on both pages, Firefox 2.0.0.13pre triggers only haaretz.com, and Firofox 3 (trunk) doesn't trigger either one.

This is probably related to bug 347426 and bug 346936.
haaretz.com and cvmarket.lt may change their pages so I've saved it and uploaded a copy for reference. They can be accessed at http://foobartastic.com/moz/haaretz.zip and http://foobartastic.com/moz/cvmarket.zip.

I've posted about this on moz.dev.extensions see http://groups.google.com/group/mozilla.dev.extensions/browse_thread/thread/9ab5c9bb2bef28a1/004839b76bc48381#004839b76bc48381

I've also included instructions on triggering, which I'm reposting here:

Here's how to use it:
go to cvmarket.lt (or use the linked zip)
open the sidebar (tools->open sidebar)
click the show the bug button
watch your error console for the error messages the extension shows
(make sure you can see chrome error messages).

The real core of the extension is in AttackRunner.js. What the runner
does is it clones the current tab. Then, on page show (which is fired
after everything is loaded), it checks if the number of forms
(and elements in each form) is the same in the new tab as in the current
tab. If they're not then an error is show in the error console. 

I'm also getting this with http://icperthshire.icnetwork.co.uk/. Probably the
entire icnetwork.co.uk network of sites.
Product: Firefox → Core
QA Contact: general → general
Version: 2.0 Branch → Trunk
Here's an easy to test example.
Attachment #306203 - Attachment is obsolete: false
Attachment #312774 - Attachment description: Better extension to show the errors. → An alternate extension, showing the results (no submits - great for testing with zipped (local) webpages)
I was examining this using (both betas and a nightly) and I got the following issues:

First got:
Error: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIWebNavigation.sessionHistory]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: chrome://global/content/bindings/browser.xml ::  :: line 582"  data: no]
Source File: chrome://global/content/bindings/browser.xml
Line: 588
in Error Console

walking through with venkman I hit: 

Error loading URL <XStringBundle>: [Exception... "Component returned failure code: 0x804b000a [nsIIOService.newChannel]" nsresult: "0x804b000a (<unknown>)" location: "JS frame :: chrome://venkman/content/venkman-url-loader.js :: _getChannelForURL :: line 54" data: no].
Error loading URL <XStringBundle>: 2147500037.

This happens really early in the add tab method. However I still get a tab.


Further walking through the extension showed that I get more errors:

Error loading URL <XStringBundle>: [Exception... "Component returned failure code: 0x804b000a [nsIIOService.newChannel]" nsresult: "0x804b000a (<unknown>)" location: "JS frame :: chrome://venkman/content/venkman-url-loader.js :: _getChannelForURL :: line 54" data: no].
Error loading URL <XStringBundle>: 2147500037.
The XStringBundle errors are because you're trying to debug XBL: bug 375401. Try enabling pretty print.

Johnny: any ideas on this one? Is pageshow unreliable?
(In reply to comment #8)
> The XStringBundle errors are because you're trying to debug XBL: bug 375401.
> Try enabling pretty print.
> 

Right. That got rid of those errors. They seem to have been unrelated.
> Error: [Exception... "Component returned failure code: 0x80004005
> (NS_ERROR_FAILURE) [nsIWebNavigation.sessionHistory]"  nsresult: "0x80004005
> (NS_ERROR_FAILURE)"  location: "JS frame ::
> chrome://global/content/bindings/browser.xml ::  :: line 582"  data: no]
> Source File: chrome://global/content/bindings/browser.xml
> Line: 588
> in Error Console

This is gone as of April 1st nightly (hope it's not an april fool's joke). It seems to be unrelated.
Confirmed that this is still a problem in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1
When I Run XSS Me for one of the web applications, For all the forms, i find error and it doesnt generate the Report of XSS ME Result. 

Please find the screenshot attached with this bug[XSSResult_Issue]. For me the Severity is Blocker. because i am not able to find the results.
Attached image XSSResult_Issue
I am using XSS Me to test my pages for Security. While it works fine for a few pages, this tool fails to work completely for one of my important pages, can someone please look into this.
I am using XSS Me to test my pages for Security. While it works fine for a few pages, this tool fails to work completely for one of my important pages, can someone please look into this.
Suffering from this too. Please have a look at it!
I'm using XXS Me to test the security of my web sites and this is currently causing me some rather late nights, can this please be looked into.
Adding bz, who might have some insight.
Insight into which?  The originally filed "only reproducible in Gecko 1.8" bug?  Or the "xss me" issue which doesn't have any steps to reproduce?
OK.  Can someone please actually give steps to reproduce for the "xss me" issue; ideally ones that someone who has never used Firefox before can follow?

Probably a good idea to put them into a new bug, since I don't see what the xss me issue has to do with this bug.
(In reply to comment #22)
> OK.  Can someone please actually give steps to reproduce for the "xss me"
> issue; ideally ones that someone who has never used Firefox before can follow?
> 

The steps to reproduce are:

1. install the attached extension (attachment 312774 [details])
2. download and unzip the demo page (attachment 312773 [details])
3. view the unzipped page in Firefox
4. open the extension's side bar and click the button
5. watch your error console for the bug

Alternatively,

1. Install XSS Me
2. Go to any of the urls listed or the attached zipped page (312773)
3. open the sidebar
4. click run all tests


Expected results:

tests should run to completion

Actual results:

the extension notices that the cloned hidden tab's DOM is not what it should be and raises an error.

> Probably a good idea to put them into a new bug, since I don't see what the xss
> me issue has to do with this bug.

XSS Me is having problems because of this issue. It was wile I was developing XSS Me that I noticed this problem  - which occurs only on /some/ pages :-(.
OK.  I assume step 4 above was actually "open the tools menu and ...".  Took a bit of hunting to find that; I hope that's what you meant.

What I see is that the first time the error is logged the browser.contentDocument is about:blank (so having 0 forms is expected).

The other times, it looks like the pageshow event is coming in when the 

    <script src="CV%20Market%20-%20darbo_files/functions.js"
            type="text/javascript"></script>

node is the last thing in the DOM of the browser.contentDocument.  So presumably the script is being loaded (asynchronously).

I looked into this a bit more, and it seems like the main issue here is that the extension is issuing loadURI calls on tabs before the currently-loading document finishes loading.  When you do that, a Stop() call is made on the currently-loading document, which leads to immediate document load completion.  In this circumstance onload is not fired for the document whose load was stopped, but pageshow is fired.
(In reply to comment #24)
>
> I looked into this a bit more, and it seems like the main issue here is that
> the extension is issuing loadURI calls on tabs before the currently-loading
> document finishes loading.  When you do that, a Stop() call is made on the
> currently-loading document, which leads to immediate document load completion. 
> In this circumstance onload is not fired for the document whose load was
> stopped, but pageshow is fired.
>

"by currently-loading" do you mean in the hidden ("worker") tab? 

Would a solution be something as follows:

1. register the pageshow event listener
2. catch the pageshow event
3. process the pageshow event
4. call Stop() on the tab manually
5. reuse the tab if necessary
6. profit!

Is there a way to catch the fact that Stop was called or is it synchronous?
(In reply to comment #24)
> OK.  I assume step 4 above was actually "open the tools menu and ...".  Took a
> bit of hunting to find that; I hope that's what you meant.
> 

Yes, you're correct. Sorry about being unclear.
> "by currently-loading" do you mean in the hidden ("worker") tab? 

Yes.  So loadURI on a tab, then another loadURI on the same tab.  That will stop the previous load and lead to a pageshow event for a partially loaded page.

> Would a solution be something as follows:

I'm not sure how that would help with the above situation...
(In reply to comment #27)
> I'm not sure how that would help with the above situation...

What I'm understanding is that the problem is being caused by the implicit call to Stop().

So what I'm trying to check is whether an explicit call to Stop() before "freeing" the tab back for reuse would alleviate the root issue. And if so how can I listen for when Stop() has completely finished firing off all the events it triggers (like the pagshow event you said it fires in Comment 24).
Any call to Stop(), explicit or implicit, will trigger pageshow if it hasn't fired yet for that document.

At the moment, pageshow will fire synchronously from Stop().  Don't depend on that continuing to be the behavior, though; in particular the HTML5 spec effectively requires onload to be async, so pageshow would be too.

You could check whether a tab's document is done loading (check its readyState) to see whether you should be loading stuff in it, or to see whether you need to wait for its pageshow event when calling stop().

In any case, the bug as initially filed is invalid; the behavior when stop() happens is more or less by design.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → INVALID
(In reply to comment #29)
> Any call to Stop(), explicit or implicit, will trigger pageshow if it hasn't
> fired yet for that document.
> 
> At the moment, pageshow will fire synchronously from Stop().  Don't depend on
> that continuing to be the behavior, though; in particular the HTML5 spec
> effectively requires onload to be async, so pageshow would be too.
> 
> You could check whether a tab's document is done loading (check its readyState)
> to see whether you should be loading stuff in it, or to see whether you need to
> wait for its pageshow event when calling stop().
> 
> In any case, the bug as initially filed is invalid; the behavior when stop()
> happens is more or less by design.

Thanks for resolving this issue. I appreciate it.

However, the behavior of firing pageshow from stop() is completely undocumented in https://developer.mozilla.org/en/nsIWebNavigation. I don't mind documenting it but does it fire for both STOP_CONTENT and STOP_NETWORK or just one?
They both should.

Basically, pageshow fires whenever onload would have fired.  onload firing is explicitly suppressed if the page load ends up with an error status (whether due to explicitly being canceled or some sort of network-level issue).
Hi, I'm a Seneca College intern at Security Compass working with Tom(who posted above) on this issue.

(In reply to comment #29)
> You could check whether a tab's document is done loading (check its readyState)
> to see whether you should be loading stuff in it, or to see whether you need to
> wait for its pageshow event when calling stop().

Thank you for explaining that to us, we did not know that any stop() could trigger a pageshow and further that we should always wait for readyState to be "complete". Unfortunately, checking for readyState == "complete" has not resolved this issue.

I've attached an updated prototype that checks the readyState before loading anything into a tab. This prototype is much leaner and will only load a page once a tab's readyState == "complete". Once the page is loaded in a worker tab, its DOM is compared with the DOM of the source page. If any differences are found, they are reported through the error console.

As indicated previously, this bug does not affect every site but it does affect enough of our users for it to be significant. Run the prototype on http://www.haaretz.com/ and watch the errors pile up; note that this site loads rather slowly in North America so expect to wait...

For a happy day scenario, run this same prototype on http://demo.testfire.net/bank/login.aspx and watch as no errors are reported.

As before, to run the prototype: navigate to the desired site, click Tools -> "Open the sidebar to expose the problem" -> click "Show the bug", wait until the "end" alert marking the end of the test. Make sure to have your error console open and watch for document comparison failures.

This prototype outputs copiously to standard out so running it in the context of a -console firefox is recommended but is certainly not required. Note however that due to the large amounts of console output, the error console's reports will be delayed.

We have not implemented a graceful shutdown mechanism for this prototype so to stop it mid-run, close the sidebar and close all the tabs that it has opened. You may have to restart firefox afterwards to get all your responsiveness back.

Thanks again for helping us out with this issue.
Based on Hasan's work in comments 32 and 33 I'm reopening this.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
I Have of new this bug, its presented when i was take a test with the plug in XSS ME, for more information, in mi e-mail, hacking61@hotmail.com

Thanks.
Hi,
I have also had this bug, it showed when using the XSS ME plugin to test site security.
I wasn't doing anything special, just opened the plugin sidebar and tried running all tests...
Depends on: 739918
Same issue :( :(

When I Run XSS Me for one of the web applications, For all the forms, i find error and it doesnt generate the Report of XSS ME Result.
Me too. Running XSS ME on any page that contains a form within an active modal. Mac OSX 10.7x - FF 19.0.2
When I try to Run XSS Me on http://www.dafont.com/search.php?q=visitor i got this 420025 eror
I have not been able to use XSS at all.  It looks like a good tool but worthless thanks to this bug.  I cannot put link to form here, security.

Fix it please

Thanks
I've been able to use xss-me but not complete. I'm testing a localhost asp.net web app with it and gives me this error.
(...)
There was an error while testing this site. This was likely due to Mozilla bug 420025. Please help us track this bug by either emailing us the url to this site or commenting on the bug. We apologize for the inconvenience and hope to have this fixed soon.

XSS String Tests Summary (100 tests executed)
(...)

I really don't know where the error gets fired, but I hope this helps.
Thanks for the work and your attention.

Regards.
Same issue here with XSS Me. Trying to run some tests on a client's site and it's totally inoperable. Site's HTML5, Javascript/jQuery.
Getting "There was an error while testing this site. This was likely due to Mozilla bug 420025. Please help us track this bug by either emailing us the url to this site or commenting on the bug. We apologize for the inconvenience and hope to have this fixed soon."

URL : http://www.samsclub.com/
Dear all,
Please, help me to explain the mechanism of action of XSS Me and it's report
Thanks.
+1 from XSS ME plugin!
Hi,

XSS-Me crashed on this site: http://goredpocket.com/easyrefill
Any ideas?

Cheers,
Michael.
Using some extension on some of the sites Causing issues, high severity according to the standard of mozilla
Maybe this is already obvious to everyone; but I do not see it mentioned specifically anywhere here.  It seems to me, that the majority of issues I have seen with this bug and using XSS Me and the majority of examples listing "problem sites" above have one thing in common: asynchronous javascript loading in additional content.
From my experience, if you pass a form variable from the primary working page into an asynchronously loaded page/content, XSS Me is guaranteed to provide an error.  At least that is my experience.  It seems that since the primary document finished loading, XSS Me thinks that the whole page finished loading even though additional content is being loaded into the page asynchronously.
To add an example to comment 54 above, perform a XSS Me test of the URL below:
http://64.94.101.150/battlefield/index.php?p=leaders&sid=6

Since the form "ajaxsearch_leaders" is located inside of a page "/common/player/player-search.php" which was asynchronously loaded in from "index.php" it almost instantly triggers the bug every time.

Other pages from the same site don't have the issue as long as they don't have forms or certain form data located inside of content which is asynchronously loaded.
Continuing on with more discovery....
If the offending page is placed into an iframe and loaded in from another URL, there is no problem since XSS Me stops parsing the problem data within the iframe.
This all sounds like issues with the XSS Me addon and not with Gecko. Please bring this conversation to the issue tracker for that addon, this is not the right place for discussions about that. And AFAICT there is no bug in Gecko here, so I'm going to mark this bug as invalid. Thanks.
Status: REOPENED → RESOLVED
Closed: 14 years ago8 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: