Topic awaiting preservation: Firefox JavaScript/DHTML capabilities/peculiarities (Page 1 of 1)

Okay, reactions from InI, bugimus and a few others here have prompted me to make this post. In not-that-short, the question I ask you is this:

What are the scripting/DHTML related peculiarities - nothing theoretical, give me code examples please - that you feel Firefox has? For what reasons do you think those are peculiar? How differs moz from ie in these cases? Are saf, iem, op7 also similarly affected, or is it a moz specific peculiarity?

--
var Liorean = {
prototype: HTMLGuru.prototype,
abode: "http://codingforums.com/",
profile: "http://codingforums.com/member.php?u=5798"};

liorean, it is entirely possible that some of my objections are my fault. I'm just so frustrated with cross-browser issues that I may be taking it out undeservedly on Firefox.

I am having problems opening new HTML windows with my popup script and getting rid of the scrollbars even though I have them turned off. I am also trying to find a reliable way to compute the size of the chrome around the popups so I can create windows that hug images perfectly. I have a few more things to try before I post the code to see if it is my failure or not. I have found a way to do this in IE and I did have a way of doing it in a previous version of Opera but now that no longer works either

: . . DHTML Slice Puzzle : . . .

Bugimus: regarding your problem of scrollbars with your popups, have you checked that you set correctly the overflow:hidden; in the BODY of the popup ? Now about resizing a popup to the size of an image, I just used the DOM inspector to double check that the document object has the width and height attributes and the BODY tag has the clientWidth and clientHeight attributes giving the inner width and height of a page. Thus at worst it's fairly easy to tune the size of a window to match the resolution of a picture.



(Edited by poi on 11-11-2004 10:50)

Thanks very much. I will give those a try and let you know.

: . . DHTML Slice Puzzle : . . .

AHA!!! That did help! Thanks, poi

But shouldn't 'scrollbars=no' in the open method have worked?

Check out this page for a demo of what I've come up with so far.

http://www.bugimus.com/dhtml/bugLib/bugLib1.0_Test/imagePop.html


Now on to another problem. I have seen this mentioned elsewhere in the Asylum and I don't understand it. On my home page, it loads up ok but the status bar never displays "Done". It will remain at "Transferring data from www.bugimus.com..."

On simple HTML pages things seem to work fine but if I'm loading images via script dynamically, this behavior occurs. I cannot figure this one out.

One thing I noticed is that once the page loads and is in cache. If I come right back to it after visiting another page, the "Done" status appears. It seems to only occur when it's loading fresh from the server.

: . . DHTML Slice Puzzle : . . .

(Edited by Bugimus on 11-12-2004 18:01)

Glad that helped. The 'scrollbars=no' is almost useless since the default value of the overflow property is auto. Therefore if the body/content of your popup is bigger than the popup itself, even by one pixel, some scrollbars will added.

Sorry, I don't know about the message in the status bar. Actually I've often seen crazy things there, like the status of one tab being applied to all the others.

In most cases, it's a server issue with IIS servers - To increase browsing speed in the competition with Netscape, Microsoft made IIS not close connections. This means that the browser is still prepared to recieve data for display - such as the next page when you click a link - without having to take a roundtrip to the server to synchronise the connection. Of course, this caused the effect that Internet Explorer on one hand is faster at communication with an IIS server than other browsers, but also has the effect that it is slower than other browsers at connecting to non-IIS servers. It also has the mentioned effect of leaving the browser open for more data instead of closing the connection. There are other causes for it to happen, but this IIS behavior is quite common. The reason for it not to happen when you return to the page from history is that it returns the in-memory representation of it, which does not leave an open connection.

--
var Liorean = {
prototype: ProgrammingTheoryGuru.prototype,
abode: "http://web-graphics.com/",
profile: "http://codingforums.com/member.php?u=5798"};

What?!?

First this I believe (and I've had 11 beers in a 12 pack) that Bugs is talking about Firefox which makes that a bit irrelevant.

Second, are you saying that IIS doesn't close connections to IE? As in Socket connections? Do you have some sort of documentation to prove this? Because (if I'm understanding you in my buzzed state) you're saying that IE and IIS doesn't close socket connections and if that we're true IIS would olbe virtually unusable by breaking the HTTP as a protocol.

Methinks this is more of an issue with the way firefox caches stuff than a server side issue.



.:[ Never resist a perfect moment ]:.

well, http1.1 does specify a keep-alive, which let's the session stay open - so you can do something like that without 'breaking the HTTP as a protocol'.

Then again, as far as I remember, this was disabled in IE for some security reason some time ago.

I just noticed that in IE I get "Copy Post to Clipboard Before Submitting" option here in the Asylum. But in Firefox that option does not exist and instead of "copy" and "paste" buttons, there is just a "highlight" button in Firefox. What's the story behind this difference as it relates to this thread?

: . . DHTML Slice Puzzle : . . .

Bitdamaged: I'm talking about TCP connections and no, not conforming to conventions doesn't break any protocol transfering on top of TCP such as HTTP since the connection is still made, just with a bit more work. As for keep-alive, that's an HTTP command and works above this level (though it does change the TCP connection).

When a TCP connection is opened, the standard way things are done is that first you synchronise the connection with the server, then you send the request, then the server sends data packets, you acknowledge them. When the request is finally finished, the server sends a connection close, which the client responds to by acknowledging and sending a connection close, which the server acknowledges. This acknowledgement is vital here, as it is what effectively closes the connection. IIS does not send it.

What happens with IE, is that it tries to begin with sending the request. Server may here either tell it that it's an illegal transaction or simply ignore it and let it time out. Anyway, if the request does either of those, ie will do it the regular way and do the synchronisation. However, if the server doesn't acknowledge the close of connection (like IIS), and ie sends a request in this manner, it will serve the the file without having to synchronise again. This optimisation as I mentioned costs a roundtrip (and ev. timeout) for other servers, but at the same time saves a roundtrip for all following requests to an IIS server.


Note that this behavior was found for IIS on WinNT 4.0 back in 1997, and doesn't necessarily affect more modern versions. (I haven't seen any more recent documentes on this.)

--
var Liorean = {
prototype: XMLGuru.prototype,
abode: "http://codingforums.com/",
profile: "http://codingforums.com/member.php?u=5798"};

Bugs -
when I wrote the scripts for our new reply box here around this time of last year, IE was the only browser that would let you copy and paste to/from the clipboard through JavaScript, which is why we're doing a bit of browser sniffing to hide the "copy post before submitting" box and show the "highlight" button instead of the other two when a browser that isn't IE comes along.
By now this might well have changed and I'm not at all up to date - if you or anybody else knows of way to do it in FF let me know and I'll see what I can do.

Thanks for the explanation, kuckus

Ok, about the "Transferrring data forever" status bar message, I think I found how to avoid it although I'm still not clear if that behavior is a bug, peculiarity, or something else in Firefox.

For years I have always loaded my image swap scripts after the onload event triggers. It seems that loading up images this way is what causes the message to appear. So I embedded the function call that creates the images into the body of my page and this prevents the behavior. I am ok with this now that I know but is this a bug or what?

: . . DHTML Slice Puzzle : . . .

yeah I believe so, I've seen it being mentioned as an issue on the mozillazine forums, although I don't believe it has high priority as the page still actually loads and functions correctly, it just isn't communicated correctly to the user.