Thread
Classilla 9.1
I posted this to the macos9 list, but I'll also post it here. Obviously, you can get it from www.classilla.org. 68kMLA finally renders correctly!
Letting Classilla bake a couple more weeks isn't likely to make it any better,
so I'm releasing 9.1 today.
I was unhappy with some of the bugs that snuck into 9.0.4, some of them not
in portions of code I used much, but others I should have noticed, and a
few of those regressions were serious. I've tried to avoid doing that in 9.1
and the most important regressions I introduced in 9.0.4 are now fixed. I am
not fully happy with 9.1, but I think it is an important enough update to
release even in its current form and I apologize to the community for not
having beaten on 9.0.4 more before I released it. 9.1 is what 9.0.4 should
have been.
9.1 is primarily a layout update. I managed to find a fix for infamous issue
65 that prevented layout from advancing further, and was able to restore the
overflow branch. This layout update handles overflow space management much
more correctly, which is an opaque way of saying that the blank spaces you
see on a lot of sites in 9.0.4 will now be properly filled with content. In
fact, 68KMLA renders right for the first time in any Mozilla-based browser
on the classic Mac OS. This also means the dreadful experimental renderer
hack is no longer needed, and has been removed. There are other minor layout
fixes. These don't work 100% on all the pages that used to -- in particular
Apple's nav bar gets "ghosted" for reasons I can't figure out -- but the
number of sites that now work greatly outnumbers the ones that work less.
Also, widget and view code have been revamped to avoid a number of the
scrolling and graphical glitches that plagued 9.0.x. Many of the "scroll
turd" bugs have been quashed by the overpainting scroller in this release.
This makes scrolling a bit slower, but makes the display much higher quality.
For the few sites that can't scroll correctly at all, there is a View > Use
Slow Scroll which forces additional repaints (but is also slower still,
as the name would suggest). Those sites are rare.
Plugins can also now be disabled completely, which reduces a common source
of display instability (turn off plugins if you don't have Flash).
Finally, a few sites that hit worst-case scenarios during reflow now have a
mitigation. While the sites will still appear to hang the browser, you can
abort layout by holding down Cmd-. (Command-Period) and come to a safe halt
without force quitting. This may cause the page to not fully lay out, but you
can navigate on it, and the operation is safe and requires no restart. Paypal
comes to mind here.
Just as 9.0.4 was mostly a JavaScript update, so will 9.2. However, I really
just need to rewrite it from scratch, and we'll talk more about that when test
versions become available. 9.3 will be the next layout update, but I have to
think about how to accomplish it. Despite being still mostly Mozilla code,
Clecko has patches applied in different order and different ways, and it is
getting harder to port arbitrary Mozilla code to it. It's still possible, but
harder. However, a lot of porting will be needed to get a later Mozilla layout
into Classilla, let alone everything else, and it may not even work. I have
to weigh the best way to accomplish that.
Right now, though, you can get it as always from www.classilla.org
and have fun.
Sounds great. I look forward to trying it out.
Thank you a lot.
Your work fills a great hole in mac os classic today usability.
All mac classics users must be gratefull.
Sorry for my english.
Your work fills a great hole in mac os classic today usability.
All mac classics users must be gratefull.
Sorry for my english.
Thanks! I'm checking it out now and posting from my B&W running 9.2.2. It's so cool to see a modern forum render correctly under Mac OS 9. My machine doesn't feel so old now :lol: . Thanks for all the work you're putting into this.
A lot more pages are working correctly now. Thank you for your efforts. Keep going!
Thanks for the kind words, everyone. JavaScript next!
Just downloaded and installed the latest version. Everything seems to work better so far. I can load FaceBook on my G3 without using the mobile site, and sites seem to all around load faster.
ClassicHasClass, You are THE MAN! Your efforts are highly appreciated! Thank You!
I am still on all sorts of Classic and won't be switching to OsX anytime soon. Only if the bastards will force me to.
The beauty of the Macintosh for me is the possibility to 'throw together" the operating sistem by combining CP's and extensions and not going to any sort of command line. Wasn't that the main feature that made computing so understandable to millions of people?
OK, enough, I'll rant about that resorce hungry GUI on top of the Unix somewhere else :-D
ojfd
Please, please! It drives me nuts that I can't navigate normally on some sites, especially eBay.JavaScript next!
I am still on all sorts of Classic and won't be switching to OsX anytime soon. Only if the bastards will force me to.
The beauty of the Macintosh for me is the possibility to 'throw together" the operating sistem by combining CP's and extensions and not going to any sort of command line. Wasn't that the main feature that made computing so understandable to millions of people?
OK, enough, I'll rant about that resorce hungry GUI on top of the Unix somewhere else :-D
ojfd
Cheers! This is terrific. I only discovered Classilla about two weeks ago, and I love it. You have our gratitude!
What macos9 list?
What macos9 list?
LEM's.
You received this message because you are a member of the Mac OS 9 group.
The list FAQ is at http://lowendmac.com/lists/macos9.html and our netiquette gui
de is at http://www.lowendmac.com/lists/netiquette.shtml
To post to this group, send email to macos9@googlegroups.com
To leave this group, send email to macos9+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/macos9
Support for older Macs: http://lowendmac.com/services/
You received this message because you are a member of the Mac OS 9 group.
The list FAQ is at http://lowendmac.com/lists/macos9.html and our netiquette gui
de is at http://www.lowendmac.com/lists/netiquette.shtml
To post to this group, send email to macos9@googlegroups.com
To leave this group, send email to macos9+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/macos9
Support for older Macs: http://lowendmac.com/services/
Great!
Yesterdays Youtube "layout change" killed youtube usage in Classilla. Even if they call it only a "layout change" it made all my Classilla setups to be unable to playback any video! Did someone already find out if there is a way to go on watching youtube videos?
Yesterdays Youtube "layout change" killed youtube usage in Classilla. Even if they call it only a "layout change" it made all my Classilla setups to be unable to playback any video! Did someone already find out if there is a way to go on watching youtube videos?
I seen to recall reading a popup thing from them(or possibly elsewhere) about cutting backward compatibility.
avw, I don't use Flash on OS 9 (on purpose), so can you tell me what it's doing wrong, or post a screen shot?
OK, I uploaded an screenshot here: http://www.freeimagehosting.net/uploads/0c3de1af1c.jpg
(BTW ImageShack is also not working anymore because of an "javascript: void(0)")
The problem at Youtube seems to be ugly javascripts. It´s a similar problem whith all embedded videos since years (wamcom and Netscape 7). The control buttons are not acessable at all. The flash content is not displayed. If I reload the page or scoll, it´s possible to see the original size of the video window inside tha youtube page, but the video window gets too big - independend from the page size. So I did an screenshot in 1600 x 1200 to understand what I mean. No control button is availaible, no further informations inside this video window down to "category" and "tags" which never fit inside the actual window size! Maybe one problemm is that "" tag? But I don´t understand much about it.
Another intersting thing, I can nowhere see a link while mouseover - even if i can access some parts of the new page by clicking inside this black video window, ...
(BTW ImageShack is also not working anymore because of an "javascript: void(0)")
The problem at Youtube seems to be ugly javascripts. It´s a similar problem whith all embedded videos since years (wamcom and Netscape 7). The control buttons are not acessable at all. The flash content is not displayed. If I reload the page or scoll, it´s possible to see the original size of the video window inside tha youtube page, but the video window gets too big - independend from the page size. So I did an screenshot in 1600 x 1200 to understand what I mean. No control button is availaible, no further informations inside this video window down to "category" and "tags" which never fit inside the actual window size! Maybe one problemm is that "" tag? But I don´t understand much about it.
Another intersting thing, I can nowhere see a link while mouseover - even if i can access some parts of the new page by clicking inside this black video window, ...
Unfortunately, I'm not so sure that this is just a JavaScript problem -- in Camino 1.6.11 (1.8.1.23) the page also lays out very badly, despite (nearly) up to date JavaScript. I think this is primarily a layout issue, and that's going to be very hard to repair because the layout upgrade I'm envisioning for 9.3 at best gets to 1.8.1 also (1.7.13 plus non-Cairo patches). I'm not sure if I'm going to be able to fix this for awhile. However, does destyling the page help you at all?
Thanks for your quick reply! Destyling doesn´t help anything. The video will also not load and not be shown at all, and not be controllable (no control buttons etc.)
Maybe there is something doable with the iPhone version? But I don´t know if the mpg4 versions used for mobile safari are decodeable with MacOS 9 at all?
So thanks again for your efforts! Be sure I know about your work for MacOS 9. I´m angry at that company which is able to kick us - with a simple "layout change" - back to where we´ve been with Mozilla 1.2, ...
Maybe there is something doable with the iPhone version? But I don´t know if the mpg4 versions used for mobile safari are decodeable with MacOS 9 at all?
So thanks again for your efforts! Be sure I know about your work for MacOS 9. I´m angry at that company which is able to kick us - with a simple "layout change" - back to where we´ve been with Mozilla 1.2, ...
OS 9 doesn't (natively) do MPEG-4. I might be able to remedy this in the not so distant future however
That being said, interestingly enough, if I disable JavaScript and load the page it (almost) appears normally, except the plugin is not loaded. When I destyle the page with JavaScript on, however, I *do* see the plugin frame. Can you post a screenshot of that so I can see what you're seeing? Does that plugin frame not work either?
A while ago when I was working on 9.0.4 I had an idea for "agents" for troublesome sites on a case-by-case basis that acted as helpers when the browser itself was unable to handle the content. The helpers would pull links and content out of the page and give basic functionality (so in this case, pulling out the embedded video links so you could at least download the video, even if you couldn't do anything else). This is not a road I want to go down because then I end up writing up a huge batch of exceptions instead of fixing core problems, but it might be what we have to do in the interim.
That being said, interestingly enough, if I disable JavaScript and load the page it (almost) appears normally, except the plugin is not loaded. When I destyle the page with JavaScript on, however, I *do* see the plugin frame. Can you post a screenshot of that so I can see what you're seeing? Does that plugin frame not work either?
A while ago when I was working on 9.0.4 I had an idea for "agents" for troublesome sites on a case-by-case basis that acted as helpers when the browser itself was unable to handle the content. The helpers would pull links and content out of the page and give basic functionality (so in this case, pulling out the embedded video links so you could at least download the video, even if you couldn't do anything else). This is not a road I want to go down because then I end up writing up a huge batch of exceptions instead of fixing core problems, but it might be what we have to do in the interim.
OK, sorry that it took me a while.
Here are two pictures. The first one with JS disabled:
http://www.freeimagehosting.net/uploads/68f3d0bc81.jpg
The second one destyled - the same page.
http://www.freeimagehosting.net/uploads/288057732a.jpg
The idea about downloading the video might be fine. If it works with not too much efforts - fine! But don´t take too much time for it, better go on with general development.
Here are two pictures. The first one with JS disabled:
http://www.freeimagehosting.net/uploads/68f3d0bc81.jpg
The second one destyled - the same page.
http://www.freeimagehosting.net/uploads/288057732a.jpg
The idea about downloading the video might be fine. If it works with not too much efforts - fine! But don´t take too much time for it, better go on with general development.
The destyled page has JS *off*. What happens if you turn it *on* but keep it destyled? (Reload if needed)
Well, there heappens not very much, ...
A small video box appears, but there are no navigatin buttons again, and there is no video or audio at all, ...
http://www.freeimagehosting.net/uploads/9e18a8450b.jpg
A small video box appears, but there are no navigatin buttons again, and there is no video or audio at all, ...
http://www.freeimagehosting.net/uploads/9e18a8450b.jpg
Any chance that HTML5 or a subset of it might be in the not too far distant pipeline to implement or at least consider/contemplate? There's a working draft spec for it at http://www.w3.org/TR/html5/.
avw, thanks for trying, at least. It seems the new YT layout has screwed up a lot of other older browsers, too.
Nathan, HTML 5 is in my pipeline, but not imminent (I FAQed this since I get asked it a fair bit
). Many of the document tags are secretly already in the parser, but the really glitzy stuff will be hard. I might support and by, if nothing else, offering download links, but this also requires a piece on the other side to translate the video into something QT 6.0.3 can play (i.e., also porting ffmpeg, or at least libavcodec). That's getting a little ahead of myself, especially since I don't have HTML 4.01 working fully yet (getting there!).
I'm ploughing through the diffs for JavaScript in the meantime. Btw, Classilla 9.1 even in its old brown state can run the SunSpider benchmark. Just be prepared for a long wait: on my TiBook/867, it clocked in at a horrific 53000+ ms. For comparison, Classilla 9.1 under Classic on my quad G5 took 25000+ ms, and Firefox 3.6.3 on the same hardware took just 4100. Got some work to do there.
Nathan, HTML 5 is in my pipeline, but not imminent (I FAQed this since I get asked it a fair bit
). Many of the document tags are secretly already in the parser, but the really glitzy stuff will be hard. I might support and by, if nothing else, offering download links, but this also requires a piece on the other side to translate the video into something QT 6.0.3 can play (i.e., also porting ffmpeg, or at least libavcodec). That's getting a little ahead of myself, especially since I don't have HTML 4.01 working fully yet (getting there!).I'm ploughing through the diffs for JavaScript in the meantime. Btw, Classilla 9.1 even in its old brown state can run the SunSpider benchmark. Just be prepared for a long wait: on my TiBook/867, it clocked in at a horrific 53000+ ms. For comparison, Classilla 9.1 under Classic on my quad G5 took 25000+ ms, and Firefox 3.6.3 on the same hardware took just 4100. Got some work to do there.
I just did a processor swap in my G3 today, and decided to do a little messing around online and I found that Facebook's status updates page no longer loads. I just get the blue toolbar, an inch of empty space, and then the bottom of the page. I've messed around with the preferences, but nothing seems to help. Also, the rest of the site seems to work fine. I can view profiles, change my options, post comments on pictures, and use applications without any real trouble, its just the status updates part that doesn't work.
I'll be honest; I'm surprised anything with Facebook works at all. It uses fairly sophisticated scripting. I will be looking at, at minimum, supporting Facebook Lite for 9.2 with JavaScript, but I hadn't had much luck with it previously and I'm impressed it was working for you at all before.
Facebook Lite has been dropped/abandoned, so no point there really.
... which is a shame, because I quite liked Facebook Lite.
But I do have some new news to report: I just pulled the switch on the new JavaScript interpreter in my internal build. There are still some glitches, but the SunSpider benchmark dropped from 31 seconds on the 1.8GHz build MDD to 16 seconds -- half the execution time! Also, eBay now works right. I'm ironically enough having some trouble with unresponsiveness in Facebook -- this might not be JavaScript but could be weirdness with XMLHTTPRequest, so I have to go through that code as well. But even as it is now, Facebook actually works, somewhat. And remember that Mozilla uses JavaScript as glue code just about in everything, so the whole browser is faster.
Btw, this improvement is "only" with SpiderMonkey, the pure C implementation. I'm not sure if I can wring TraceMonkey into Classilla, but if I can, hold onto your hats -- performance could shoot up another full level with that. There is a PPC nanojit but I'm a little leery on whether CodeWarrior can digest it.
Also, this is a major internals change and I bet there will be regressions I haven't noticed yet. But 9.2 is on the horizon!
But I do have some new news to report: I just pulled the switch on the new JavaScript interpreter in my internal build. There are still some glitches, but the SunSpider benchmark dropped from 31 seconds on the 1.8GHz build MDD to 16 seconds -- half the execution time! Also, eBay now works right. I'm ironically enough having some trouble with unresponsiveness in Facebook -- this might not be JavaScript but could be weirdness with XMLHTTPRequest, so I have to go through that code as well. But even as it is now, Facebook actually works, somewhat. And remember that Mozilla uses JavaScript as glue code just about in everything, so the whole browser is faster.
Btw, this improvement is "only" with SpiderMonkey, the pure C implementation. I'm not sure if I can wring TraceMonkey into Classilla, but if I can, hold onto your hats -- performance could shoot up another full level with that. There is a PPC nanojit but I'm a little leery on whether CodeWarrior can digest it.
Also, this is a major internals change and I bet there will be regressions I haven't noticed yet. But 9.2 is on the horizon!
Sounds hopeful(hopefully)
:rambo:
:rambo:
Well, we have a problem with TraceMonkey already. This is important -- if you are a 601-based Classilla user, I need to hear from you ASAP (post in this thread).
TraceMonkey fetches the processor's timebase using mftb/mftbu instructions. While these technically exist on the 601, they work completely differently from the 603 on up, and CodeWarrior refuses to use them or compile (if I force the issue with 'machine 601' I get a compilation error). This is a critical portion of the nanojit's inline assembly code and cannot be coded around. It does compile if I use 'machine 603' or 'machine 604', so it is clearly an architectural limitation.
This means that 6100, 7100, 8100, 7200 and 7500 users, and any other 601 Power Macintosh, cannot use TraceMonkey as written. I need to know *now* if you are such a user -- if there is a significant number of 601-based systems out there using Classilla, I will not continue with TraceMonkey at this time. I can't even guarantee I can port it to the 603 or 604, although if I encounter incompatibilities with those, then TraceMonkey is a no-go because I know of many people using systems with those CPUs. However, I already know that the 601 is dead in the water unless there is someone with bigger PPC assembler gonads than I that knows a solution to this. (johnklos? trag?)
This should not affect you if your system has an upgrade card in it -- I am pretty confident that the instruction would be handled by the upgrade card, not the internal CPU, even on systems where the original internal CPU remains present. I can't promise this, however, especially for weirder upgrades like the 7200 Sonnet CPU card.
If I am unable to port TraceMonkey, and it was sort of a long shot anyway, the updated SpiderMonkey will still be in Classilla 9.2 and even that is still a significant improvement, so this is hardly catastrophic. But please, speak now if you are using a 601 system with Classilla so I can at least do some future planning.
TraceMonkey fetches the processor's timebase using mftb/mftbu instructions. While these technically exist on the 601, they work completely differently from the 603 on up, and CodeWarrior refuses to use them or compile (if I force the issue with 'machine 601' I get a compilation error). This is a critical portion of the nanojit's inline assembly code and cannot be coded around. It does compile if I use 'machine 603' or 'machine 604', so it is clearly an architectural limitation.
This means that 6100, 7100, 8100, 7200 and 7500 users, and any other 601 Power Macintosh, cannot use TraceMonkey as written. I need to know *now* if you are such a user -- if there is a significant number of 601-based systems out there using Classilla, I will not continue with TraceMonkey at this time. I can't even guarantee I can port it to the 603 or 604, although if I encounter incompatibilities with those, then TraceMonkey is a no-go because I know of many people using systems with those CPUs. However, I already know that the 601 is dead in the water unless there is someone with bigger PPC assembler gonads than I that knows a solution to this. (johnklos? trag?)
This should not affect you if your system has an upgrade card in it -- I am pretty confident that the instruction would be handled by the upgrade card, not the internal CPU, even on systems where the original internal CPU remains present. I can't promise this, however, especially for weirder upgrades like the 7200 Sonnet CPU card.
If I am unable to port TraceMonkey, and it was sort of a long shot anyway, the updated SpiderMonkey will still be in Classilla 9.2 and even that is still a significant improvement, so this is hardly catastrophic. But please, speak now if you are using a 601 system with Classilla so I can at least do some future planning.
While I do have a 6100 (with a NewerTech Nupowr G3 250Mhz CPU upgrade card with 1MB L2 cache,) I don't run Classilla on it. (the clock battery is dead so L2 cache won't enable.
) However if you need Classilla tested on such a machine I'm more than willing to test it for you.
) However if you need Classilla tested on such a machine I'm more than willing to test it for you.
Just for curiousity's sake, can Classila even be run on a 6100 with it's original cpu? If so, is MacOS 9 the only OS version it will run on?