Steffan Cline

Steffan,

> I was trying to build my own web mail client in Lasso (like php) and saw
> your scripts.

I was wondering how long it would be before someone got inspired by gmail ;)

> I can see how you do this but what about file attachments?

Ok, you are starting to use the wrong techniques. To put it simply, you
should not try to replace the browser's own form handling when it comes to
sending files. In order for you to do this, you would need to read in the
contents of the file from the user's disk. This is not possible, as reading
files on the user's disk would be a security violation.

Also, only IE on Windows is capable of reading files like that using
ActiveX, one of the major causes of IE's security problems. Other browsers
are sensible enough to prevent it. Even so, IE will not allow it as it
would be a cross domain scripting violation.

If you want to submit a file, you must use a standard file submission form,
and submit the form normally. That is the only way that browsers will allow
you to access files on the user's computer.

> I use the DOM to allow the ability to add all the
> file references needed.

You may run into problems with browsers not sending the dynamically
generated inputs to the server. Most current browser releases should be OK
though. IE on Mac will fail. Opera 7 will fail, Opera 8 will work (that's
OK because Opera 8 is the first Opera version to support XMLHttpRequest
anyway). Mozilla/Firefox will also have problems if you use a XHTML instead
of a HTML content-type.

> On the other pages I will have it so that when
> you get mail, it will send the details to the appropriate page and then
> parse the xml returned and place it in the div. Do you think that doing it
> this way instead of loading it in an iframe is a bad idea?

Not a bad idea, but you will lose support for many browser versions, such
as Opera 7.x-, Safari 1.1-, Konqueror (all versions), OmniWeb, and all
older browsers. You will also be relying on a non-standard technology, as
XMLHttpRequest has not been made into a proper standard yet. You may be
forced to change this if a standard is made that is not identical to the
current de-facto standard.

> Also, in your script for importXML I see that you use get rather than
> post. Is it ok to change this to accommodate more data?

By all means, change whatever you want, but note that my iframe workaround
for older browsers (including Opera 7 - the browser I currently use) will
not work if you use post instead of get. I think that you will need to make
your own variable=value data pairs, and base64 encode it, then use
send(theDataYouPrepared) - or maybe that is just how you send file data in
IE. I have never tried this myself, so I am not entirely sure.

> I apologize for all the questions.

Not at all - hope what I have said is useful.


Mark 'Tarquin' Wilton-Jones - author of http://www.howtocreate.co.uk/

> One tactic I did in the past was to submit the form to a page that had a
> header of 204 which is No Content.

I agree, this sounds like a bug, and it's certainly not a behaviour that I
would rely on, as browsers may choose to display a 'friendly' error message
to the user.

> Honestly, I only intended on supporting Safari 1.2 or firefox or anything
> which will support all the features I plan to have.

Here's your list ;)
Safari 1.2+ (beware of link tags!)
Opera 7.6+
IE 5+ on Windows
Mozilla/Firefox/etc
OmniWeb 5.1+

Generally, that covers all the main browsers. My script will extend this to
a few more, such as Opera 7.x, but if you change to using POST, then you
will lose this. Hopefully, Opera users will be able to upgrade.

> BTW, care to critique my coding or offer any
> suggestions? Any help on this one is appreciated!

To be fair to you, it's pretty good. No sniffing involved, so you get extra
bonus points :)

Steffan,

OK, first negative point :)

I am an Opera user, and you won't let me use the page. Opera 8 is perfectly
capable of handling XMLHttpRequest. The windows and linux versions are
currently in beta, and the Mac version is in technical preview:
http://my.opera.com/forums/showthread.php?s=&threadid=78078

Since most of the page diagnostic tools I have written are specially for
Opera, I am pretty much lost without it.

I have managed to live edit your source code to make Opera read a fixed
version, but I am now getting another problem, in Opera and Firefox. I
cannot open your test page. In Firefox, I 'click here to start' and a new
window appears then immediately closes itself. In Opera, the login form
appears, so I tell it to log in, and the window closes itself. This is the
offending line of code:
onblur="window.close();"

This can cause real problems, as clicking on form inputs or loading a new
page can constitute bluring, as can a dialog from another program that
forces itself to be in focus. Even worse, Firefox has a nasty bug where
clicking on parts of the window also contitutes a blur, and the browser
will crash.

Again, I have edited your page source (this is one feature of Opera that
is invaluable when testing other people's pages) to remove the forced close,
and told Opera to reopen the closed page, reloading it from the edited
cache (another excellent feature). So, I now have your page sitting in
front of me :)

Anyway, back to your original points :)

> I was asking if you wanted to be a part of the team on this
> and donate a little time.

I'm afraid that is not possible. I have a few life changes going on at the
moment, and they are taking up a lot of my time. But I should always be
here for specific problems you need help with.

As for your "foo" <foo@bar.com> problem, the XML is perfectly fine, and you
are doing that part correctly. But from the look of it, it looks like you
might be using something like innerHTML to write this new content on the
page - this will re-interpret your text as HTML, which would cause the
problem you describe. Since what you are importing should be treated as a
text node, you should simply be able to make a new text node in the page
and add the new text content into it.

If you need to use something like innerHTML, you should use:
yourString.replace(/&/g,'&amp;').replace(/</g,'&lt;').replace(/>/g,'&gt;').replace(/"/g,'&quot;')

However, I cannot see the error you describe, so maybe you managed to fix
it already.

As separate points - these are things that you may already have on your
list of things to do, but just in case...:

When I get new mail, it does not check for duplicates, so I always get
duplicates of the mail that I already have.

When I have over 10 items, clicking on the 10th item selects the first item.
Clicking on the 11th selects the second item, etc.

There does not appear to be any way to select multiple items, such as
Ctrl/Cmd+click or Shift+click.

None of your images are pre-cached, making the rollover effects slow and
jumpy:
var i = new Image(); i.src = 'mymouseOver.gif';

Delete does not appear to be possible yet.


Anyway, hope that lot is useful to you :)

Tarquin

> If I can find a good JS that will check the browser for
> compatibility, then I will definitely use that. Know of any good ones? ;)

http://www.quirksmode.org/dom/contents.html (incorrectly says that Opera
cannot import XML, but that's because he does not use XMLHttpRequest)
http://www.quirksmode.org/dom/w3c_core.html
http://www.quirksmode.org/dom/w3c_html.html
http://www.quirksmode.org/dom/w3c_events.html (made into a complete mess by
IE which insists on using proprietary syntax for everything)

Opera actually has better support for most things than Safari. (Neither of
them do DOM 2 CSS stylesheet editing, but almost no-one uses that anyway).

He does not cover things like mutation events (which work perfectly in
Opera and Mozilla/Firefox but crash Safari), DOM textrange (as far as I
know, Safari does not support this, and Mozilla uses its own methods for
parts of it).

The point is that instead of out and out blocking the browser from entering,
you should ask the browser if it supports the technologies you wish to use,
and if not _then_ lock it out. That way, if someone uses a browser that is
capable of using the script but you did not realise it, they will still be
able to use it. At the moment, you are unnecessarily locking people out
from your page for using a program that serves their needs, and is actually
quite capable of running your page, if only you would let it in.

I recommend you remove your server side sniffer, and replace it with a
client side support detect, which will much more accurately say if the
browser is good enough to handle the script, as it can actually test for
the technologies you are using (you don't seem to allow IE/Windows in
either, which is also capable of handling XMLHttpRequest, via its own
ActiveX handling - my script supports this):

... in your CSS ...
#goodEnough { display: none; }

... in your HTML ...
<span id="goodEnough">
 <input class="button" onclick="login();" 
 type="submit" value="Click Here to Start">
</span>

<span id="notGoodEnough">
 <img src="images/alert.gif" align="absbottom">
 <font color="red"><b>The browser you are using is
 not supported in this release.</b></font>
 </span><br><br>
 <span class="big">The required browser is ... etc
</span>

<script type="text/javascript"><!--

var isGood = false;
if( window.XMLHttpRequest ) {
isGood = true;
} else {
try { isGood = new ActiveXObject( 'Microsoft.XMLDOM' );
} catch(e) { try {
isGood = new ActiveXObject( 'Msxml2.XMLHTTP' );
} catch (e2) {} }

if( isGood ) {
document.getElementById('goodEnough').style.display='inline';
document.getElementById('notGoodEnough').style.display='none';
}

//--></script>

Exactly what browsers you promote on your page is up to you (although for
my personal satisfaction, I would love to see Opera in the list :), but
please do not block browsers that are actually capable of handling your
script.

> Your mail server originally bounced the message I had sent you

:( I hate when that happens

> I just need to figure out a way to say that they have already been
> loaded.

Since they all (are supposed to) contain unique message IDs, in theory you
should be able to use them. The XMLHttpRequest can send a list of all
headers that it has, and the server can only send new ones. Or stamp each
message with a received date, and the XMLHttpRequest can say the last date
that it has in its list, and the server can send only the ones that arrived
since then.

> > There does not appear to be any way to select multiple items, such as
> > Ctrl/Cmd+click or Shift+click.

> There is no DOM function for that so I am not sure if I need to have an
> event monitor or just check for the shift key immediately after the click

onclick="doWhatever(event)"

function doWhatever(e) {
if( e.shiftKey ) { ... }
}

You can do the same with ctrlKey (on windows) and metaKey (on mac).

> > var i = new Image(); i.src = 'mymouseOver.gif';

> Will this preloading work with the css

Yes. As long as they are in memory, it doesn't matter what uses them, HTML,
script, or CSS.


Tarquin

> May I ask what you normally do for a living? With this much experience
> I would think you can write some truly awesome stuff.

Thankyou :)

As it happens, I do not work in this field at the moment, I am currently an
email administrator. The closest I get to web pages is modifying webmail
templates. But that may be about to change ....

Most of the web stuff I have done has been small projects for companies,
basically freelance stuff, or just personal sites.