Skip to main content
Home Forums Classilla's future focus Classilla's future focus
Thread

Classilla's future focus

Classilla's future focus Development 31 posts Sep 25, 2011 — Nov 17, 2011
Posted to macos9, but also here for your consideration.

Now that Classilla.org is back in operation (mostly -- I have to do somefine tuning) it's time to figure out what its future will be.

TenFourFox changes the picture greatly because it requires significantly more

work to keep up with Mozilla's rapid release schedule, and it necessarily

has higher priority because if we fail to make a release, we will fall off

the schedule and become very behind very fast.

More to the point, the layout transplant which was the intent of 9.3.0 is

failing behind, has no guarantee of working, and even after it is done (if

it gets done) the browser will still be technologically antiquated.

Finally, the computers that are able to natively boot OS 9 and require

Classilla are, even if things such as TenFourFox's JavaScript compiler

could be ported to Classilla, increasingly underpowered for the modern web

and this won't get better.

From the beginning Classilla was never about designing the most functional

browser for Mac OS 9, merely a secure one that could be used safely for

regular tasks. So now it is time to return to the original mission, by

completing the security audit and then allowing Classilla to be a fully

functional citien on the mobile web which is a better fit for OS 9 computers.

Your comments suggested.

- 9.2.3:

- Complete outstanding new security issues, such as the DigiNotar certs,

and the eventual solution of the BEAST SSL issue.

- Various small system bugs.

- 9.3.0:

- Consider new network stack (fix OTLook issues with certain sites; issue

161).

- Destyling to be sticky for all sites.

- Add destyling directly to interface.

- Add Android user agents.

- Remove User Agent prefpanel and integrate directly into interface.

- 9.3.1:

- Complete remainder of security audit.
I should also do G3 and G4 optimized versions (so it would have a 60x, G3 and G4 set (7400 vs 7450 if CodeWarrior supports it), as TenFourFox has G3, G4 and G5).

I'm looking forward to seeing the future direction of Classilla. And I also like your idea of CPU optimised versions - if you did a 60x optimised version depending on the performance I may once again start surfing the web on my 1400.

The other thing I'm thinking of is a Greasemonkey-like interface for custom user scripts. We can't use Greasemonkey per se but a framework in the same spirit is certainly possible. Then people can use "assistants" for certain sites.

(In order of importance) I'd go with:

1. Security

2. Features (CSS & Javascript)

3. Speed, but considering what it's running on, Id say its pretty fast as-is and cpu tailored builds will only help to accentuate that.

[off-topic]

Is there anyway to make it remember all tabs that were open, not just the first one?

[/off-topic]

2, however, requires layout. That's what I don't think I'm going to be able to do except in small ways. That's why I'm pushing for destyling.

The JS engine in it is as good as Camino 2.0's, which is old, but still considerably less old than what was there before (or any other OS 9 browser).

The tabs should be getting remembered, but I don't know if that was finished for Moz 1.3. I'll have to look.

Security will now be job 1, like it was originally intended to be.

Please excuse my lack of knowledge, but what is Destyling?

Also, I do like the idea of helper scripts for websites.

If you change the style sheet to None, which is always an option, the CSS formatting is stripped off and the page appears as bare text and images. This can be useful for troublesome pages, and often renders considerably faster.

The idea is now to make that a part of the interface rather than have to go through a couple menus.

The helper scripts should be able to hint to the browser that this site needs (or doesn't) JavaScript, or this site needs (or doesn't need) styling, so that the user can be assisted and efficient default settings chosen.

Thats making me unhappy!

TenFourFox changes the picture greatly because it requires significantly morework (...)
Seems X is killing 9 again, ...
Please consider that there are good browsers for X like Opera 10 etc. But there is no good browser for 9 and 8.6. For people who need 9 you are recently the only (!) chance for a better browser. And a G4 machine around 1GHz should absolutely be enough for recent JavaScripts and CSS. (Just look at all the small ARM Netbooks that are as well not "powerful")

So please try to not focus on X what may become a real problem for Classilla.

TenFourFox, at least for the short term, has to occupy the front burner because if we fall off the wagon (drop source parity), we won't be able to get back on it. I want to get as many revisions ported to 10.4 before we give up and go to feature parity. Because Mozilla is pushing releases out so fast now, it forces me to make it job 1 because we won't get another chance at it. If I tried to make the leap from, say, 3.6 to 7 now, it would be insuperable odds. It only worked out because I had already done the work in 4, 5 and 6, so I could carry that forward. And 8 is turning out to be a death march -- there were a huge number of widget changes I need to port back to 10.4.

Also, do remember (since you point this out) that most of the ARM-based browsers have some sort of ARM-targetted JavaScript compilation: they are not strictly using the interpreter. Fennec, Android and Safari all can compile JavaScript to ARM object code, so they will run much faster on seemingly more limited machines. The JS interpreter in Classilla is from Firefox 3.0.19, and has no facilities for compilation. Porting the current Mozilla JS (including the JS PPC tracing compiler that TenFourFox uses) is probably close to impossible within CodeWarrior's limitations; porting 3.5 and 3.6's interpreter may be possible, but would require some rewriting of the TenFourFox tracejit to make it compatible, let alone worth the effort. The bottom line is that this is, at best, non-trivial.

Mozilla has given us a way off the treadmill in the LTS releases, but even so (and the LTS releases are only a plan so far), the minute we give up, the technological growth of Mozilla on any Power Mac dies, requiring me to adopt the piecemeal approach with Classilla. This worked for a lot of things, and even worked well for some things (JavaScript), but less well for others (layout and DOM). So for the time being, 10.4Fx gets first crack at the development resources I have available and Classilla gets what I can do with the remainder until source parity ends. It doesn't end Classilla development, but it is admittedly a temporary drop in its priority, and I know this won't make you and others happy. However, I'm just one guy, after all. :(

TJust look at all the small ARM Netbooks that are as well not "powerful"
What small ARM netbooks? Two years ago they sounded like "the next Big Thing", performance comparable to Intel's solutions but at half (or less) the power draw, but I just haven't seen that come to pass. I'd love an ARM notebook - running BSD or Linux with a 10+ hour battery life would be very cool - but I just don't see them around.

Actually, the ASUS EEE Pad Transformer is the ARM-book I'm looking at. I was playing with one at Fry's and it is an amazingly functional device. Whatever they've done to it, Android works surprisingly well with a trackpad.

Well about ARM book, there are as well the "NTP Firstview"s for example. But you are right, I was talking about the Atoms, ...

Well Cameron, I can in general understand you. But it is still, that we have no other alternative than Classilla. X users have. Thats hard, because I doubt that we will see an updated iCAB. So seeing you trying to stay with Mozillas releases with T4F makes me fearing, that you will completely stay there and we "just-9-users" are lost. Sorry for that hard words, but thats how I am feeling.

Maybe there should be calls for other developers for Classilla as T4F? What about the people who maintained FireFox up to 3.6 for X ?

But I have a TouchPad. Your Eee Pad is invalid.

On the downside, it isn't very responsive to touching small links on massive pages and typing on a touchscreen is a bitch.

Maybe there should be calls for other developers for Classilla as T4F? What about the people who maintained FireFox up to 3.6 for X ?
Mozilla themselves maintained the Power Mac Firefox. I appreciate the effort, but they never had anyone on their staff particularly adept at the architecture, and Apple was busy with Safari and WebKit. Camino will abandon PowerPC with "Camino 3.0," whenever that is (their post-Gecko release).

As far as Classilla, I've been asking for developers for years. No one has stepped up to the plate. We do have localizers, and that is something, but I'm pretty much the only person writing code.

Give them a crash course in Codewarrior, perhaps? :p Maybe we should start working on newer development environments for Mac OS 9.

I just think there should be a way to teach interested developers how to code for the platform. You might try to get in touch with people who wrote software for Mac OS 9 and ask them if they would like to contribute.

Camino will abandon PowerPC with "Camino 3.0," whenever that is (their post-Gecko release).
This is what I don't understand at all. Will the Camino 3 code just suddenly stop compiling on a PPC platform? Or are they just not bothering to build an official release for PPC? It's going to be a pretty sad day when I can't get a "current" browser for my G5. We have TenFourFox for now, but who knows how long you'll be able to keep it going.

Is any of your work still being accepted back into the Mozilla tree, CHC? As I recall, you did some nice PPC-optimization stuff a while back.

Maybe we should start working on newer development environments for Mac OS 9.
And that would be great. A more up-to-date gcc MPW tool would be a fabulous start. You might even be able to bootstrap it with the existing gcc MPW tool. If you can get up to and over gcc 4, fat city, dude. But even gcc 3.x would be better than nothing and would compile relatively late Firefoxen (at least Mozilla 1.8 level, maybe even 1.9.0). The problem there is writing a widget library for OS 9, and the build system, but those are partially solved problems.

This is one serious advantage the Amiga community has: they have a maintained toolchain. We don't. CodeWarrior, mercifully, was far ahead of its competitors, so it remains still pretty functional.

Will the Camino 3 code just suddenly stop compiling on a PPC platform?
This is not clear, but my guess is it will not build on PPC. Camino 3 -- and I note for the record there is no guarantee Camino will live that long, but I digress -- will jump to WebKit and WebKit2 should be in full swing by then. It is questionable that WebKit2 will build as is on 10.5 by that time, and I guarantee it won't build on 10.4 (it probably has dependencies on the posix_spawn family of functions to implement its split process model; they don't exist in 10.4 and we code around them right now in TenFourFox). WebKit is reasonably system-independent, but most of the features that Camino will require will probably need 10.6 at a minimum. I can't really fault them for not wanting to continue to support 10.5.

Some of the PPC stuff is being accepted back, but I'm only submitting the POWER-generic code and not the Power Mac specific optimizations because Mozilla really doesn't want to be supporting Power Macs even with TenFourFox being a well-regarded port. While in fairness most folks at Mozilla are sympathetic to supporting PPC in the cross-platform portions of code (JavaScript, layout, etc.), their OS X-specific widget and gfx maintainers aren't (the guilty know who they are). In fact, TenFourFox 8 probably uses less than half of the official Firefox code in its widget library after all the rewriting I've been doing over the last week and I'm likely just going to spin off widget/src/cocoa/ and */themes/pinstripe into widget/src/tiger and */themes/tigerstripe instead of dealing with all the post-10.4 crap they're loading them with (CoreUI, NSTrackingArea, etc.).

it probably has dependencies on the posix_spawn family of functions to implement its split process model; they don't exist in 10.4 and we code around them right now in TenFourFox
Does this mean porting WK2 to A/UX is a non-starter? Dang! ;) :lol:

Safari is a good Webkit browser, and then there's iCab, Omniweb, and Shiira too. Do we need another? The point of Camino was "Mozilla power, Mac style"—so why keep it now?

That's exactly my point.

But then I think WebKit will eat the web anyhow. We will damn it in the same tones we damned Internet Explorer, you mark my words.

I always hated internet explorer. IE6 came out, and i turned against it real quick. always called it shiternet explorer and i wont ever go back to it. lol.

Just a point of order:

Classilla isn't slow. Not by any stretch of the imagination.

3. Speed, but considering what it's running on, Id say its pretty fast as-is and cpu tailored builds will only help to accentuate that.
CPU-tailored builds may not actually be able to do much, I'm afraid. The issue isn't with Classilla's use of the CPU, it's actually pretty performant even on a 225MHz 603, and on a 400MHz G3 it screams. The problem is that it's Mozilla. As in, the whole of the Mozilla Application Suite. And all that functionality which doesn't really get used that much takes up a lot of RAM. Let's face it, Communicator's always been a pig, Mozilla didn't fix that shortcoming at all. If there's any real speed enhancement to be made, it's making Classilla light enough that it doesn't have to page VM all the time - if it could be stripped down to the browser alone Classilla would be a damn sight faster and snappier.

And Herr Kaiser, if I manage to teach myself Classic Mac OS Programming, you bet I'll try to penetrate the mysteries of the Mozilla codebase, you may very well have a new coder. Alas, probably not soon, for I am a bear of little brain. :)

...like Firefox, but for OS 9?

Firefox got very chubby nowadays; SeaMonkey is a lot nimbler.

I didn't mean that to sound as though it is slow. I meant, that considering the low end CPUs it is running on, it does very well at doing things that the rest of the world feels needs a 3GHz+ Multi Core cpu to do.

CPU-tailored builds may not actually be able to do much, I'm afraid.
I didn't say they'd make a big difference, but there should be a difference.

On the note of helping: I plan to step-up as a distiller once I get some real HTML/CSS/Javascript courses under my belt next year. Most of the stuff I currently know about those standards is likely basic enough that it wouldn't be causing problems.

...like Firefox, but for OS 9?
No, no. More like Netscape Navigator to Classilla's Netscape Communicator. But yes, for OS 8.6 and 9.

it does very well at doing things that the rest of the world feels needs a 3GHz+ Multi Core cpu to do.
Well, you see, I have this strong suspicion that the sort of people who make Web 2.0 sites and use AJAX and do things that need eleventy million megahertz to render properly tend to be the same sort of people whose sites suffer for want of stimulating content, so it's generally no skin off my back if any of my Power Macintoshes is incapable of rendering facebook :p

I always hated internet explorer. IE6 came out, and i turned against it real quick. always called it shiternet explorer and i wont ever go back to it.
Heh, we called it Internet Exploder. Yuck yuck yuck!

Firefox got very chubby nowadays; SeaMonkey is a lot nimbler.
I always find this so ironic, since FF was developed to replace the slow, bloated Moz App Suite. "Just a browser!" everyone screamed, so they split out the browser. "Don't throw in the kitchen sink!" everyone shouted, so they developed add-on capabilities. But it's still huge.

Actually, I'm pretty happy with Firefox nowadays. Doesn't help us much in OS 9, alas, but TenFourFox is (in my biased dictator opinion) a lot zippier than 3.6, and not all of that is the PPC-specific work.

Still, Mozilla 1.x is still pretty fat.

Speaking of fat, posted to macos9. This is unlikely to affect, well, anybody, but if you are using these tools you are officially on notice.

This is unlikely to affect anyone, but just in case, 9.3.0 will probably notinclude viewer, RegXPCOM or PPEmbed -- no one uses them, I don't maintain them

and PPEmbed has some issues building now, and they simply add bulk to the

release. They are holdovers from an earlier age and it is time for them to go.

People who want to build from the source code can still get them, but they

will no longer be built by default nor included with future releases of

Classilla. If you are actually using these files for something, plead your

case in Classilla issue 179.
mp.ls