SM 2.49.4 Javascript severe lag / freeze

[webmoebius]

I've been using SM 2.49.4 since its release, under the same operating system and hardware environment without any major problems but suddenly some very odd things have been happening with SM browser dealing with ordinary scripts. There have been no changes in operating system resources such as available RAM. The only thing that has changed is that the display resolution is significantly higher with a much larger Windows desktop space than before, basically nearly double the resolution an pixels. After this Windows desktop size change, the SM browser started behaving oddly this way. However, I have still basically been using a similarly sized browser window albeit with a taller height. But since this change on the system, suddenly there have been many, many web pages I routinely use without problems including web mail services, that have started to have HUGE lag times in what appears to be executing in-page scripts. To the point where my ABOUT:CONFIG parameter of DOM_MAX_SCRIPT_RUN_TIME which I had already previously increased to 25 seconds more than a year ago without problems, has become insufficient to eliminate the SCRIPT CONTINUE PROMPT dialog box, I had to increase the time out parameter to 40 seconds.

However, it's baffling why SM browser engine is now doing this with scripts when the only thing that has changed is the increased Windows desktop resolution. It's very annoying because a lot of pages causes temporary browser freeze and clicking on it results in the Windows window title bar display application NOT RESPONDING for a while and then SM continues working normally. I can't fathom how display resolution would affect SM browser engine or Javascript engine performance like this. I have not yet tried loading pages with Javascript disabled as a test to see if it's a Javascript engine problem or a browser engine problem, but I suspect it's the former. Since the script time out prompt arose. It makes no immediately sense. Any suggestions or clues to investigate this problem would be appreciated.

This message was posted via SM 2.49.4, with a browser user agent string override.

[Frank Lion]

Any suggestions or clues to investigate this problem would be appreciated.

Thanks for the wall of text.

I suggest you start with the basic troubleshooting steps of SafeMode - http://kb.mozillazine.org/Safe_mode and testing with a clean, additional, profile - http://kb.mozillazine.org/Creating_a_ne ... on_Windows (the SM procedure is basically the same as Firefox)

[webmoebius]

I suggest you start with the basic troubleshooting steps of SafeMode

My immediate hunch is something much much more specific. While the catch all generic solution is to test in safe mode, in the decades I've been using Mozilla browsers and solving / pinpointing problems, I've actually found that I've rarely if ever had to use that mode. I've since determined that its not related to this issue.

[webmoebius]

Update - as I suspected, since the issue arose immediately after display size increase to a much higher than normal value and since the script time out warning prompt appeared, my suspicion became more focused on script related issues, since many web pages uses script routines to detect / determine screen size. After checking the SM browser ERROR CONSOLE, I noticed a lot of logged errors related specifically to a CSS component loaded in web pages I use frequently (such as web mail log in) that relates to user display data (e.g. display size detection, etc) that SM browser engine chokes on decoding. This is probably because there is some type of bug in either the Mozilla Gecko browser engine and/or the loaded code from the page that results in an error condition which causes the script engine to choke on it and then the script engine times out after a long duration (many seconds later). As expected, this very same issue now occurs consistently on Firefox-ESR browser as well, since SM and FF are both using the same Gecko engine, basically.

I don't suppose there's any ABOUT:CONFIG configurable parameters where one could override the returned screen resolution of the display environment in which the SM browser is running in? If there is, I would love to know the parameter specifics (name / data type / values) and punch in my old values on a much smaller Windows desktop to fool these types of display detection code so that it wouldn't choke on it.

[Bac_a_sable]

resolution here and all fine:

2560x1440 on screen
1680x1050 on secondary screen.

What is your resolution?

[webmoebius]

resolution here and all fine: 2560x1440 on screen 1680x1050 on secondary screen. What is your resolution?

Currently same as your main monitor's resolution. Have never had any problems previously on various other resolutions on my and other user's systems including 1024 x 768, 1280 x 1024 and 1600 x 1200. Since the issue I'm having affects both SM and FF browsers, yet only occured immediately after resolution and desktop space increase, I'll have a look at other possible system level issues that are somehow affecting Javascript on both browsers.

[frg]

I doubt that it helps but remove xulstore.json from your profile. This should reset any saved Window settings and sizes.

Which graphics card? QHD is pretty hefty even compared to 1600x1200.

For clarification. Does it only occur if you switch resolution while SeaMonkey is running or from the start?

FRG

[webmoebius]

I doubt that it helps but remove xulstore.json from your profile. This should reset any saved Window settings and sizes. Which graphics card? QHD is pretty hefty even compared to 1600x1200. For clarification. Does it only occur if you switch resolution while SeaMonkey is running or from the start? FRG

Tried deleting XULSTORE.JSON from the SM profile's folder, but that didn't make a different to the issue itself. Oddly, deletion of that file didn't result in a complete reset of window positions and size. It seemed to have reverted to the original window sizes when this SM installation was running under 1600 x 1200 resolution mode. So I wonder where SM got those older settings from outside of XULSTORE.JSON. However, keep in mind that I found that this script freeze issue is present also on Firefox-ESR 52.90 as well, so it isn't just a SM problem. I think we might be getting slightly warmer though not by much.

Graphics hardware is just motherboard built-in on-board graphics which is AMD-ATI Radeon connected to the monitor via DVI-D dual link video cable (which would support up to 2560 x 1600 at 16:10 aspect ratio for this Radeon chipset). No problems playing back commercial DVDs and BDs under VLC-Player. I do intend to update the driver but from what I read it would perhaps just improve graphics performance optimization a bit which I doubt is the issue here. And since this system is used for playing games either, I'm not holding my breath that driver update will make a different to a browser script execution issue. There are so many error entries in the SM browser error console, some point to display related scripts / style sheets. I wish I could easily copy multiple error console entries. Possible that the issue is one of those buried in the error console warnings.

[therube]

If you revert to your prior screen resolution, do the script issues subside?

URLs where you run into these script issues?


frg nagged me for quite a while before I finally updated my Intel HD graphics.
When I did, it helped .

[TPR75]

URLs where you run into these script issues?

Open Google Maps, select a road trip (from/to) for a car and try to zoom-in. In most cases I've got lag in SeaMonkey or even freeze (hardware acceleration disabled). Works correct in 2.53 so I think it is related to old Gecko... or stupid changes on website(-s) because few months ago it was working without problems...

[webmoebius]

If you revert to your prior screen resolution, do the script issues subside? URLs where you run into these script issues? frg nagged me for quite a while before I finally updated my Intel HD graphics. When I did, it helped ;-).

I do plan to update the AMD/ATI graphics drivers to their final available version sometime soon, but want to at least do a complete system drive C image back up first before doing anything. That drive partition is due for an image back up in any case and it'll allow me to easily revert the system to its previous state if something messes up.

Large number of sites that uses Javascript appears to cause this issue, including even major web mail sites and shopping sites (e.g. Amazon / E-Bay), none of these sites of which I had any problems whatsoever previously. All these issues suddenly and immediately occured after only just the resolution change in the system with absolutely no other hardware change, so I don't see why it wouldn't revert to its previous normal state if I reverted the resolution to lower values. I will be testing this as well soon to confirm that the issue reverts to normal, though I haven't immediately done so because reducing resolution will screw up some Windows window sizes I have since set up when Windows desktop resolution increased. I'll post some site URLs that trigger this problem a bit later when I follow up on this.

[webmoebius]

Open Google Maps, select a road trip (from/to) for a car and try to zoom-in. In most cases I've got lag in SeaMonkey or even freeze (hardware acceleration disabled). Works correct in 2.53 so I think it is related to old Gecko... or stupid changes on website(-s) because few months ago it was working without problems... :x

Google Maps crash is a known issue on both SM and FF browsers of more recent versions. I find that the crashes and freezes occurs very quickly after a few pans in Google Street view, though not in Google Maps - only in Street View for me. For this reason I have Opera for Windows installed just to use it for Google Maps, since the Chromium browser engine appears to be most compatible with Google Maps / Street View. However, the Google Maps / Street Views problems are complete browser crashes, not temporary lag / freeze then recover to normal operation. So this is something different. I also discovered that Google News recent new format in the last year also causes SM browser to take ages to render and often the page doesn't display / render / format correctly, so I've stopped visiting that site as well (though this is not an unrecoverable crash, just an inordinately long page rendering lag).

What's also odd however, is that since the increased resolution, many Google maps embedded objects in web pages displayed in SM browser (and presumably in FF-ESR browser as well) have refused to go full screen map mode. Very bizarre. When I click full screen mode in an embedded Google Maps object on a web page, it briefly tries to go full screen but without displaying any content full screen, immediately flips back to embedded windowed mode. I'm going to guess that somehow the object failed to return / detect the correct screen resolution, couldn't go full screen and then crashed back to windowed embedded mode. This suggests that it may have something to do with SM/FF browsers failing to detect or returning an invalid screen resolution when it attempts to do detection. I believe that this is where the culprit lies as I continue to investigate this.

[therube]

(Save a screenshot of your desktop, to show where you icons were, in case they get jumbled by a resolution change.)

[webmoebius]

Save a screenshot of your desktop, to show where you icons were, in case they get jumbled by a resolution change.

That I'm not worried about - I have only 4 desktop icons all of which are Windows system icons. No program app icons as I keep it neat and they are all on Internet Explorer's Windows quick launch bar.

[Bac_a_sable]

Browser full sceen on main monitor: google map works. It is cpu consuming but all is ok
No graphic card, just intel chipset HD graphic on main board.
Connected via display port.