Netscape 4 support?

[ericmackrodt]

Hi,

I have been testing this tool and it's incredible! I was wondering if it's possible to make it run on Netscape 4, even if it's a slightly more limited experience.

If so, I could potentially help with that if I was pointed in the right direction.

Thank you!

[ericmackrodt]

I'm trying to do it, I'm just unsure how to edit the html pages on the fly so I can test it as I go. Do I need to recompile every time I change the files?

[ttalvitie]

Great! I haven't really tried Browservice with Netscapes that old, so I'm not sure what works and what doesn't; you might be in for a challenge. Netscape 6 was discussed in issue #3; to image reloading work (in a flickery fashion), it needs the fix from commit 827d13a4fc73f60209e97ad41f9c3d25aaa5df4b. However, it may be that the issues with Netscape 4 are completely different, as Netscape 6 was based on Firefox, while Netscape 4 was not.

The Retrojsvice HTML templates are compiled into the binary, so you cannot edit them on the fly. However, if you only edit the HTML templates, the incremental recompilation with make should be very fast, because it only needs to recompile the HTML template module and relink the executable. On my computer, it takes less than 2 seconds.

The code for the JavaScript client in main.html is a bit weird, because it has been written with compatibility in mind. For example, things like Array.push or non-string arguments to setTimeout could not be used as old browsers do not support them and there are state flags all over the place to avoid running into the quirks of IE event system. Feel free to ask if you need me to explain something about the code.

[ericmackrodt]

I have managed to swap images on Netscape 4 but the CSS support is very limited. I'll keep trying here and see where I get to.

[ericmackrodt]

Hmmm, this is very difficult. I can on a separate html file load images on the fly on Netscape 4 with some trickery but for some reason I can't get it working with browservice. I'll keep trying, but I wish I could start simpler, just load one image first. I feel it's a bit hard to make changes to support NS4 the way the js code is structured, there's a lot going on there.

[ttalvitie]

Debugging JavaScript code on old browsers is indeed quite hard. You probably should trace how the code works and where it stops working for the first time; for comparison, you might want to do this on another browser on which it works. If NS4 does not have a usable JavaScript console you could write trace log to, you might need to get creative; for example, at some point, I appended text to window.status and document.title for debugging.

[ericmackrodt]

I usually use alert() with NS4. I kinda managed to load the PNG from Browservice in NS4 and replace it. I have to use only one tag, so the code there will end up very different. I could potentially load the image within an image object and then replace it in the main task, but the problem is that that is considered a second request and when I do that request I get an "outdated request" response because browservice only allows me to request that image twice. Which is weird because I'd imagine NS would cache that image, as it did with my test application. Maybe NS4 does a check with the server to see if you can load that image before displaying the cache, but that's just a guess, it's really hard to find information about those behaviors.

Another problem I found, which I don't know if there's a solution, is that I can't change the size of the image on the fly. After it loads for the first time it stays that size forever. I can change the size of the image on the request, which would return a different size, but the image component would remain the same size causing the image to potentially be distorted as well as not fitting with the browser window.

[ttalvitie]

Do I understand correctly: You can have only one img element for the browser view, probably because NS4 does not support the CSS/JavaScript trickery required for double buffering using two or more image elements. You try to achieve somewhat atomic updates by preloading the image into another (non-visible) img element and after it has loaded, load it in the visible img element, hoping that it is cached.

The image request handling logic is in the Window::handleImageRequest_ function in viceplugins/retrojsvice/src/window.cpp. In principle, Browservice allows the same image to be requested multiple times; the only constraint is that the image index must be non-decreasing. So if you have already requested image 57 but you re-request image 56, you get "outdated request" response; this may be the reason why you are getting the error. This non-decreasing constraint is a sanity check, meant to avoid old requests using up capacity; you can remove it from this line.

But as you say, the real issue is that the image is requested again instead of being cached. The reason for this is that for simplicity, all Browservice HTTP responses include cache disabling HTTP headers (except for file downloads, where we disable those headers to circumvent IE bugs). This is controlled by the noCache argument to HTTPRequest::sendResponse implemented in viceplugins/retrojsvice/src/http.cpp; the argument defaults to true. You should try to set it to false in the sendResponse calls that send the image responses here and here by appending false to both sendResponse argument lists. I am not sure if removing these headers is sufficient to make NS4 cache the image or if you actually need to add some headers (you can do that using the optional argument extraHeaders in HTTPRequest::sendResponse). You should check that the headers are correct by looking at the response headers in the developer tools of a modern browser.

As for the image size issue: Can't you manually set the width and height of the image element to match the ones you set in the request (does NS4 support it)? Note that it might take a few frames for the image size in the responses to actually change to match the requested size.

[ericmackrodt]

Exactly, you can only have one img element, and you can use the Image object to load images in the background, as long as you have cache enabled.

Set the parameter to enable cache with NS4 did work, I managed to get it semi functional in this branch: https://github.com/ericmackrodt/browservice/tree/netscape-4

The javascript apis on NS4 are completely non-standard.

The issue I have now is that, when I click on the address bar, the text is selected briefly and then the field loses focus. Is that something you encountered in the past?

I can definitely manually set the width and height in the html file, but that size would be set forever for the img element, I'm trying to use 100% for width and height, which works as soon as it loads, but again, it doesn't update. Also I need to remove the margins on the page completely otherwise the mouse is off.

Edit:

I managed to make it look closer to what it was intended on NS4 by using layers, as they support zIndex. Here's a branch with that experiment: https://github.com/ericmackrodt/browservice/tree/ns4-layers

It's however noticeably slower than the previous approach and I still haven't resolved the issue of text fields losing focus.

[ttalvitie]

I've had issues with various browsers with focus out events. You should try logging to see which events are received from the JavaScript side; a good place to do that would be the beginning of Window::handleTokenizedEvent_ in viceplugins/retrojsvice/src/window.cpp, as every event passes through it. You should try comparing the events you get on NS4 and some other client browser that works correctly and see what is different.

If you are still debugging the JavaScript side with alert message boxes, keep in mind that the alerts might mess up the state of the browser (for example, it probably causes loss of focus). Logging to window.status, document.title or some textarea might be less invasive in this sense.

I'll try to get around to setting up a NS4 test VM and trying your branches at some point.

[ericmackrodt]

I logged the event like you suggested and I was getting an FOUT event every time I clicked on a text field. It started working after I commented out the window.onblur event, now I can browse to some websites. I still have some issues though. The arrow keys don't do anything and the letter t resets inputs instead of typing the letter for some reason.

Also, I'm still having issues with image resizing, using width and height 100% resizes the image but the contents disappear for some reason.

Edit:

I also realized that in the layers branch, for some reason, only one of the layers gets its image updated, that's why the images load slowly. I could reproduce that on a simple html file, so I think netscape has some bug there.

[ttalvitie]

@ericmackrodt sorry, this issue got kind of buried... In case you are still interested in this, I tested your netscape-4 branch changes (ported to v0.9.2.2) on Netscape Navigator 4.08 on Windows NT 4.0. Some comments:

• I don't seem to get Netscape to ever resize the actual image element from its initial size. In addition, the image does not fill the window completely. If Netscape does not like resizing, one possible hack would be to force a reload on each resize.
• The issue with 't' key is caused by the following: On most browsers, when you press 't', you get keydown and keyup events for keycode 84 (the physical key code) and keypress event for keycode 116 ('t' in ASCII). However, Netscape 4 calls keydown and keyup with keycode 116 instead of 84, which corresponds to the physical key F5, causing a refresh. An easy workaround that simply disables F*, Win, Menu and NumLock keys (which could errorneously be triggered by letter keys) is to replace the line

  nonCharKeys[nonCharKeyList[i]] = true;

  by

  if(nonCharKeyList[i] < 90) nonCharKeys[nonCharKeyList[i]] = true;

[ericmackrodt]

Hi @ttalvitie , No problem. Yeah, I'm still interested. Image sizing on Netscape 4 is a huge issue, the image doesn't resize on the fly at all. The refresh might be the right solution...

I'll give it a go at some point, I need to finish up some projects.