headers
Snider, Sean | 1 May 2002 03:53
Favicon

RE: Updating the DOM when doing JS

Does anyone have a sample XPCom JS Component that does thread stuff
like below?

Sean

-----Original Message-----
From: Brendan Eich [mailto:brendan <at> meer.net]
Sent: Wednesday, April 10, 2002 11:25 PM
To: mozilla-dom <at> mozilla.org; Chris
Subject: Re: Updating the DOM when doing JS

Chris wrote:

>I have a fairly complex set of javascript code that will need to run
>for an extended period of amount of time. I have a XUL app that
>displays the progress of this code as it runs. The problem I have is
>this:
>
>The UI only updates after the JavaScript code completes.
>
>The workaround I have right now is this: I break the sequence into
>small chunks and execute each chunk separately using setTimeout to
>chain them together. If the timeout length is large enough (60 ms on
>my machine but I assume it would vary which is bad) then the UI can
>keep up.
>
>I guess what I really want to do is run this code in the backgound or
>at least give the appearance that it is. I have searched the web and
>newsgroups for a couple of days now with no luck as to how to approach
>this problem.
(Continue reading)

Permalink | Reply | 668 comments |
headers
Peter Wilson | 1 May 2002 05:10

Re: Updating the DOM when doing JS

Sean,

You say "the DOM", but what about a DOM?  I.e. can you build a document
in the other thread and then pass the completed document back to the
main UI thread, which would then display it.  Is any DOM operation even
on a non-displayed document still tied to the UI thread?

This has arisen in discussion of document.load(). If the callback
function executes in the same thread as the asynchronous load, then any
UI DOM related operations may be totally unsafe. I have asked this
before, in other news groups, and still haven't gotten an answer. I hope
you can shed some light on this.

I have heard mention of proxy objects which can be used to synchronize
communication between threads. Unfortunately, there does not appear to
be any examples in the Mozilla Javascript codebase.
Permalink | Reply | 0 comments |
headers
Snider, Sean | 1 May 2002 06:22
Favicon

RE: Updating the DOM when doing JS

Well in theory. . . 
	You could use a thread to build strings that represent a DOM object
or document and when the thread is complete simply hand this off. . .Most
other DOM operations are fast enough (ususally. . .:)).  The biggest problem
is generating a bunch of DOM object( like widgets ) on the fly, which locks
up the browser.  An thread just to build strings would be very useful.

I am just curious to see the JS code for the Thread component. . .

Sean Snider
Software Engineer I
604-456-3429
ssnider <at> ea.com 

-----Original Message-----
From: Peter Wilson [mailto:PWILSON <at> GORGE.NET] 
Sent: Tuesday, April 30, 2002 8:10 PM
To: mozilla-dom <at> mozilla.org
Subject: Re: Updating the DOM when doing JS

Sean,

You say "the DOM", but what about a DOM?  I.e. can you build a document
in the other thread and then pass the completed document back to the
main UI thread, which would then display it.  Is any DOM operation even
on a non-displayed document still tied to the UI thread?

This has arisen in discussion of document.load(). If the callback
function executes in the same thread as the asynchronous load, then any
UI DOM related operations may be totally unsafe. I have asked this
(Continue reading)

Permalink | Reply | 0 comments |
headers
Fabian Guisset | 1 May 2002 10:43
Picon

Re: Updating the DOM when doing JS

Snider, Sean wrote:
> Does anyone have a sample XPCom JS Component that does thread stuff
> like below?
> 
> Sean
> 

Ah, the wonders of LXR (lxr.mozilla.org)! ;-)

http://lxr.mozilla.org/seamonkey/source/js/src/xpconnect/tests/js/old/threads.js

-Fabian.

> -----Original Message-----
> From: Brendan Eich [mailto:brendan <at> meer.net]
> Sent: Wednesday, April 10, 2002 11:25 PM
> To: mozilla-dom <at> mozilla.org; Chris
> Subject: Re: Updating the DOM when doing JS
> 
> 
> Chris wrote:
> 
> 
>>I have a fairly complex set of javascript code that will need to run
>>for an extended period of amount of time. I have a XUL app that
>>displays the progress of this code as it runs. The problem I have is
>>this:
>>
>>The UI only updates after the JavaScript code completes.
>>
(Continue reading)

Permalink | Reply | 668 comments |
headers
Andy Cavatorta | 2 May 2002 06:44

cookies and document.load(): bug or feature?

Hi folks,
In Moz versions prior to Mozilla 1.0 RC1, cookie data was sent with
document.load requests.  Now it appears that they are not [insert
crashing sounds here].  I can find nothing about this on Bugzilla.  And
I can't find anything about cookies in the W3C's "Document Object Model
(DOM) Level 3 Abstract Schemas and Load and Save Specification".

So what's the story: bug or feature?

thanks,
andy c
Permalink | Reply | 0 comments |
headers
Gilad Taase | 2 May 2002 13:11
Picon

readyState for mozilla

I write an application that hooks into mozilla and retrieves the contents of
a web page, using C++.
I need to check if the current page has already loaded. In IE I would use
the IHTMLDocument::get_readyState method, but I couldn't find something
similar in mozilla.
When I searched old newgroup message, I found a suggestion to use a fire
event for this. How is it done?
Is there a method that does not involve an event, but just lets me ask about
the current state of the loading?

Thanks
Gilad Taase
Permalink | Reply | 2 comments |
headers
Boris Zbarsky | 3 May 2002 18:41
Picon
Favicon

Re: set focus to Document or form

Jason wrote:
> Or am I wrong in my understanding that I can place any node in focus?

That's exactly the problem.  The following nodes have a focus() method 
in the W3C DOM as it currently stands:

HTMLAnchorElement
HTMLInputElement
HTMLSelectElement
HTMLTextAreaElement
HTMLButtonElement

That's it.  You can't set focus to anything else.

In most browsers, the Window object has a "focus" method that can be 
called, but this object is outside the purview of the DOM.
Permalink | Reply | 0 comments |
headers
William JOYE | 6 May 2002 13:42
Picon

Access html page content via XUL

Hello,

I would like to build an application that can interact with the browser
content (for example the cookies in the html page). First, is it possible ?
I have tested the cookie but have always the message "undefined" when I use
'document.cookie' in my javascript.

Best regards,
William JOYE
Permalink | Reply | 0 comments |
headers
Christian Biesinger | 6 May 2002 14:30
Picon

Re: Access html page content via XUL

William JOYE wrote:
> I would like to build an application that can interact with the browser
> content (for example the cookies in the html page). First, is it possible ?
> I have tested the cookie but have always the message "undefined" when I use
> 'document.cookie' in my javascript.

Not sure if I understood you correctly, but I think you want 
"content.document.cookie".

Setting followup-to npm.dom
--

-- 
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
                                                  -- Benjamin Franklin
Permalink | Reply | 0 comments |
headers
Fabian Guisset | 7 May 2002 17:46
Picon

Re: Mysterious bugs in Moz1.0RC1 ? What am I missing?

Doctor Unclear wrote:

Not sure about the second one but here is the answer to the first one:
It's a feature, not a bug :-)
Discussion and argumentation in
http://bugzilla.mozilla.org/show_bug.cgi?id=26179

-Fabian.

> 1)
> a) If there is a carriage return (ASCII decimal 13) between the end tag 
> of the h1 element and the start tag of the p element, then Moz1.0RC1 
> will treat this carriage return as a child node (of type #text) of the 
> body element. Is this the normal, expected and expectable result?
> b) If one replaces the carriage return by a blankspace (ASCII decimal 
> 32), then Moz1.0RC1 does the same thing. Again same question.
> c) Am I missing something here? Is this a feature or a bug? According to 
> W3C recommandation, what should be the expected result?
> 
> I am pretty sure that a large majority of web designers use carriage 
> returns, blank spaces, tabs in order to visually ventilate the code, 
> ease its reading for countless reasons (debugging, commenting, etc). A 
> very strict and rigid approach when parsing a document's code, like the 
> one demonstrated in this code by Moz1.0RC1, can't help the use of DOM 
> methods and properties in coding practices.
> 
> One good point for Moz1.0RC1 is that I was able to figure out 
> Moz1.0RC1's particular behavior thanks to its DOM inspector: the 
> relevant nodes and related nodeValues (in this case, 
> non-printable/non-displayable characters) were displayed in the tree.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane