Jonas Sicking | 1 Dec 17:47 2002

Re: Edit web pages: conclusion !

> * The tree walkers doesn't like when we change the current node. The 
> solution is to keep reference on the node, go to the next then do 
> modifications.

How do you modify the currect node that makes the treewalker fail?

Just setting the .nodeValue of a node should not have any affect on the 
treewalker. However removing the current node from the tree will make 
the treewalker "fail" since it will still be pointing on the same node 
even though it now is outside the tree.

If this is not how things behave please let me know or file a bug and 
assign it to me.

Regards,
/ Jonas Sicking

Colin Phillips | 4 Dec 17:53 2002

Re: Is there a way to prevent the ctrl-click on links from opening new win?

Nevermind, I was using stopPropagation on the "mouseup" event, not the 
"click" event (it works fine on the click event).

-- Colin

Colin Phillips wrote:
> In a web page I want to turn off the mozilla feature of opening web 
> pages in a new window (or tab) when you ctrl-click on a link.
> 
> I have tried using event.stopPropagation and event.preventDefault, but 
> neither have any effect.
> 
> Any ideas?
> 
> Thanks!
> -- Colin
> 

Colin Phillips | 4 Dec 17:36 2002

Is there a way to prevent the ctrl-click on links from opening new win?

In a web page I want to turn off the mozilla feature of opening web 
pages in a new window (or tab) when you ctrl-click on a link.

I have tried using event.stopPropagation and event.preventDefault, but 
neither have any effect.

Any ideas?

Thanks!
-- Colin

Thad Hoffman | 4 Dec 18:24 2002
Picon

Re: Syntax error on startup

sorry, this posted to the wrong newsgroup, darn OS X nightly.
Had general selected but it posted to dom and returned my focus to dom 
as well. Freakish

Thad Hoffman | 4 Dec 18:23 2002
Picon

120404 nightly and 120309 nightly

css controled divs top value are rendering 10-20 pixels higher than all 
previous builds. left values seem to be fine.

Anyone else seeing this?

Thad Hoffman | 4 Dec 18:41 2002
Picon

type ahead find affecting text inputs

NOt sure if this is a dom question or not, but it affects the inputs 
which are part of the dom...

in IE and Mac builds with type ahead find, I am losing focus when typing 
text into text boxes

text start then disappear from the inputs and a "link not found" then 
"type ahead find stopped" messages appear in the status bar.

Is there a way to shut that off to see if it is type ahead that is 
messing up our form pages?

andy | 4 Dec 20:35 2002

new app: Server Push, Talkback, and no HTML

So I've built a very new way to deliver applications - all made possible by Moz's adherence to W3C DOM
standards, nimble event routing, and and general ass-kickingness.

So the interesting features of the achitecture are as follows:

1. GUI Rendering Engine: Nervemail's GUI is rendered entirely on the fly by its GUI rendering engine. No
HTML is used; only DOM scripting. And the server sends no HTML pages; only raw program data and code
libraries. So the GUI is not a web page with some moving parts; it's a canvas on which the rendering engine
freely creates, modifies and destroys elements.

2. Server Push and Background I/O: This system exchanges XML-formatted data with the server in the
background. Multiple requests can be sent simultaneously or queued to ensure that they happen in a
specific order. There is also a server push module allowing the server to call functions in the client.

3. Snap-in Code Libraries: The Nervemail client can call pull extra program code down from the server, snap
it in and run it. This allows the server to send only the code that is needed, saving download time.

4. Talkback: When the Nervemail Client encounters errors, it captures them and sends them back to the
server for later analysis. This helps bugs get fixed faster.

5. Persistent Workspace: Nervemail remembers your workspace between sessions. As long as you exit using
File-->Exit, Nervemail will remember the state of your whole workspace: column widths and sort order;
active address, mailbox, and message; selected messages; etc. So no matter when or where you next log in,
Nervemail will be just like you left it. 

6. Client Side Efficiency:  The main engine code is only 110KB.  And it runs just fine on my old 350MHz dev box.

7. Server Side Efficiency:  Since the client really does all of the work, the server does very little.  That's
why it's also only ~110KB in size (half of which is my POP3 'client' program that talks to the POP3 servers
and parses messages).  There are no HTML pages to generate; just simple XML docs wrapping raw data.
(Continue reading)

Jonas Sicking | 5 Dec 03:51 2002

Re: new app: Server Push, Talkback, and no HTML

This is freakin' amazing. Really nice to see.

Just a small bug i found:

You have some buttons that look like this:

<button OnClick="javascript:launch(...">

This isn't really correct. The onclick attribute contains a script to be 
executed, not an url that is launched. So drop the "javascript:" part 
and just have the script in there.

Regards,
Jonas Sicking

andy <at> nervebox.com wrote:
> So I've built a very new way to deliver applications - all made possible by Moz's adherence to W3C DOM
standards, nimble event routing, and and general ass-kickingness.
> 
> So the interesting features of the achitecture are as follows:
> 
> 1. GUI Rendering Engine: Nervemail's GUI is rendered entirely on the fly by its GUI rendering engine. No
HTML is used; only DOM scripting. And the server sends no HTML pages; only raw program data and code
libraries. So the GUI is not a web page with some moving parts; it's a canvas on which the rendering engine
freely creates, modifies and destroys elements.
> 
> 2. Server Push and Background I/O: This system exchanges XML-formatted data with the server in the
background. Multiple requests can be sent simultaneously or queued to ensure that they happen in a
specific order. There is also a server push module allowing the server to call functions in the client.
> 
(Continue reading)

andy | 5 Dec 06:38 2002

Re: Re: new app: Server Push, Talkback, and no HTML

Doh!  Getting sloppy in the wee hours.  Thanks for noticing.  And thanks for the compliment.

 - andy c

>This is freakin' amazing. Really nice to see.
>
>Just a small bug i found:
>
>You have some buttons that look like this:
>
><button OnClick="javascript:launch(...">
>
>This isn't really correct. The onclick attribute contains a script to be 
>executed, not an url that is launched. So drop the "javascript:" part 
>and just have the script in there.
>
>Regards,
>Jonas Sicking

andy <at> nervebox.com wrote:
> So I've built a very new way to deliver applications - all made possible by Moz's adherence to W3C DOM
standards, nimble event routing, and and general ass-kickingness.
> 
> So the interesting features of the achitecture are as follows:
> 
> 1. GUI Rendering Engine: Nervemail's GUI is rendered entirely on the fly by its GUI rendering engine. No
HTML is used; only DOM scripting. And the server sends no HTML pages; only raw program data and code
libraries. So the GUI is not a web page with some moving parts; it's a canvas on which the rendering engine
freely creates, modifies and destroys elements.
> 
(Continue reading)

Thad Hoffman | 5 Dec 18:12 2002
Picon

nightly builds event behavior

Comparing to 1.0.1 and NS 7.0<

The nightlies and 1.2 release, I am getting wacked out behavior to code
that has worked before. I am noting them here because I'm sure where 
they fall under to be logged.

1. (OS X & Windows builds) We have a logon screen, 2 txt fields and a 
button. The button fires an event that makes an XMLHTTPObj request and 
handles the xml returned from the server to determine what to do next 
(login, prompt user for options, deny access, etc....)
When the logon in incorrect, we pop up a div that states the error and 
offer them a button to refresh the page. This works fine in IE and 
previous moz/ns builds. Now however, when you click on the button to 
refresh, the div that holds the logon stuff, jumps to the right 
100pixels and does not refresh. Pressing the button a second time 
performs the proper behavior.

2. (OS X & windows builds) Similar to above, but this concerns divs 
loaded that contain tables to mimic formatted listboxes. Nothing fancy 
or ill about the code. The XML response is processed and we dynamically 
create a table and populate it with the data and add event listeners to 
the row (for click) and toggle classNames to mimic the selection, etc...
Anyway, the entire layout it css driven, the width of the div is drawing 
  too small for the css values at first, when you click a row, the div 
expands to the proper width, but doesn't perform the click event 
assigned, again a second click will then propagate the event.
If I stick a debugger statement into the event to be fired and start the 
debugger, it won't stop on the first click (the one that resizes the 
div) but does on the second click.

(Continue reading)


Gmane