Slashdot Mirror
Mozilla 1.2 Beta Released
nberardi writes "Mozilla 1.2 Beta is out. Typeahead now works on Mac and Java now works on Jaguar. On Linux, the classic theme now picks up GTK native theme. See the release notes for more info."
← Back to Stories (view on slashdot.org)
Type ahead find works on Mac Mozilla and works correctly with IME.
Linux Mozilla (in the Classic theme) will pick up the native GTK theme and HTML form controls now pick up the native theme on winXP.
Mozilla now supports link prefetching; see the Link Prefetching FAQ for details.
Mozilla Mail includes a new "filter after the fact" capability so users can create a filter and then run that filter on already downloaded mail. Filter logging has also been implemented.
A long requested feature, show toolbars as text/icons/both, has been implemented.
You can launch the browser with a bookmark group as your start page. This loads several pages into tabs at startup.
Java compatability with Mac OS 10.2 (Jaguar) has been repaired.
Wow. Do we REALLY need a story every time a new Mozilla comes out?
The text/icons/both thing should have been done LONG ago.
TWW
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
This sounds cool, but it looks like the page author has to specify what has to be pre-fetched. Due to the relatively small marker-share of mozilla, there will probably be few sites which implement this feature. Too bad, because it looks like a nice feature to me.
Like science? Comics? Wicked...
Funny By Nature
One question I have though - does it support GTK 1.2, or 2.0 (including the anti-aliasing fonts feature)?
Karma: Shagadelic (mostly affected by those tight knickers - yeah baby, yeah!)
Remember all those offline browsers and 'modem accelerators' that sucked up your modem bandwidth by downloading contantly, spidering every link on every page you visited?
While the Mozilla project is an incredible piece of work, I have to question this feature. It appears that they've designed it so that a page designer or webmaster decides what is appropriate for prefetching or not. Still, if used inappropriately, this feature could lead to more information being transmitted across the internet that is either discarded or unwanted. In a worst-case scenario, an inexperienced web designer might routinely run into his bandwidth cap or unintentionally force users who have bandwidth caps to exhaust their allowance.
If you can only download 3GB per month over your cable modem, do you really want the designer of a page deciding that your browser needs to spend time downloading ads or useless images?
For some people, this could be really useful. For others, it could be a real pain. Team-Moz, if you have any consideration at all, please adjust the default configuration of Mozilla so that this feature is turned OFF.
The next Slashdot story will be ready soon, but subscribers can beat the rush and slashdot the links early!
user_pref ("accessibility.typeaheadfind", false);
Or, to remove it completely, find all files in your installation subdirectories that match *typeaheadfind*, and delete those files.
Whilst it's great that stuff like this is being implemented, is anyone actually working on making a point and click interface to active/deactivate functionality rather than having to get users to resort to deleting or editing files?
If it's already there, for gods sake, why on earth do they insist on giving you these contrived instructions on how to deactivate it?
If the aim of Mozilla is to get a sizeable userbase and encourage developers to avoid writing for IE only then the first thing they should do is make it easy for the common computer user to do this sort of stuff without having to resort to editing text files.
Once they have to do that, then you lose and IE will continue to reign.
Avantslash - View Slashdot cleanly on your mobile phone.
So what happens when the greedy web master decides to add "rel=prefetch" to his tags for banners?
Joseph?
Well of course, that's why I"just say NO" to themes. OS themes, browser themes, any theme at all besides the defaults they come with.
Not because I don't like themes, but they are version specific for each release... and having to drop/change themes with each new release seems like more of a pain in the ass than it's worth.
Maybe someday in the not so distant future, they will build a theme utility that will adjust theme graphics to match the current GUI... but I doubt it.
So how long until I can just download it and have it working straight out of the box. What you describe is too much effort (it's easier for me to stay in Windows).
It sounds good, sure. But, I can't be the only person out there for whom it's more of an irritant than a feature. On long pages, if you accidentally type something without focusing on, say, the form box... then it'll scroll you right down to the link it thinks you want.
/is/ a place to disable it... it's definitely not anywhere visible.
I'm therefore waiting expectantly for the feature that lets you turn this *off*. I'm sure it's nice for some people, but if you don't want it, being forced to have it is a pain. If there
Seems like there's a lot of potential for abuse with this, especially given that right now you have to manually edit the prefs file to turn it off. What's to stop a page from tagging a really huge file, hosted on someone *else's* server as a "prefetch" item. Everyone who goes to page A starts "prefetching" from page B in the background - enough people do this and you've got a DOS going on.
Even if that scenario is not likely, I think it's still an odd choice for Mozilla - the philosophy behind the idea seems to be "the browser knows best and will think for you behind the scenes." On the one hand that sounds great: the browser will anticipate my next move. On the other, that doesn't sound so great... My cable modem starts blinking when I think I'm not grabbing anything and I get suspicious.
How about limiting the prefetching to pages in the same domain as the page doing the prefetching. Perhaps you could explicitly allow addtional domains for prefetching in the head of the document.
programming with Xt is not easy or intuitive and the on-screen widgets are not up to it.
No joke. To program directly with Xt is to hate your life. But I think you miss the point. Toolkits written *on top of* Xt, like Athena, OLIT, and Motif, are able to interoperate much better than say Qt and Gtk+. You can embed Athena widgets in a Motif app, or vice versa. It is not so easy with non-Xt toolkits. It helps if you think of Xt more like GDK than GTK+, like a sub-toolkit. Nobody writes apps completely with GDK, but *lots* of apps use it indirectly.
No, that would be a very bad idea. Just right now in the navigation menu of the Slashdot page I'm viewing ("Post Comment"), there are 17 navigation links, plus the category links, etc. You cannot tell me that you'll be following all of those 17 links. Web sites (and probably ISPs as well) would not like such a feature due to the increased bandwidth costs they'd have to account for.
Also note that e.g. this page has a "log out" link that I really do not want to be automatically prefetched for obvious reasons. Granted, it contains a query-string so Mozilla would not prefetch it anyway, but I imagine there will also be web sites that have log out links without query strings in the URL. And there are lots of other actions that might be associated with following a link (think prefetched one-click-shopping).
The HTTP standard (RFC2616) states that "In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered 'safe'", and if there are side effects, "the user did not request the side-effects, so therefore cannot be held accountable for them", but I wouldn't trust on web site administrators knowing this.
Sig (appended to the end of comments I post, 54 chars)
I noticed pre-caching when I read the release notes last night. In my opinion it is a major security danger.
A lot of police investigations go by the browser cache to see where you have browsed. Now you are giving control over to the cache to someone else.
It would be simple to put a link in the page source to some kiddie porn or other illegal information. You would never see the link on the page and would have no way of knowing what had been inserted in your browser cache until the police inform you of how long you are going to be in jail. Sure, it is possible that the police won't use the browser cache as proof of guilt (don't bet on it), but that requires a lot of trust. And if they want to be technical about it, it is technically illegal to possess that information, no matter how it was acquired.
And the gain isn't at all proportional to the risk. No pre-caching is done except on sites specifically engineered for it. That means next to none.
$5 / month hosted VPS on linux = awesome!
And that, my friend, would be the end of the Internet. How many of the links on a website do you generally click? On slashdot, I think, it would at most be something like 5%. Let's say 5% of the users would enable this feature. Now their browsers start pre-fetching. Since they normally only click at most 5% of the links, preloading all would multiply their bandwith-usage by 20 times. So. Our 5% of the users uses 20 times as much bandwidth as they would without preloading. So the average bandwidth-usage for web-browsing would about double and that's with only 5% of the users having this feature enabled. Bye bye Internet. There's a reason this really simple to implement feature isn't there yet.
But.... combined with a reasonably large distributed network of caching proxy-servers, pre-fetching might be worth a try.
0x or or snor perron?!
It sounds good in theory, but once you use you realize that pages have far more links than you thought. A typical page can have 20 or 50 links, only 2-4 of which you would be interested in prefetching. Just look around on this page for a good example. It ends up furiously downloading pages, movies etc for as much as your connection can bear, and it's not good for anyone.
The Mozilla approach could actually work. If any designers ever decide to use it.
Maybe I'm missing the standard for it (I'm not on the bleeding edge of things), but I was looking at the HTML 4.01 link rel types and can't find "preload". Fortunately, according to the FAQ, "next" will do just fine.
This is a not nit-pick, but with all the touting of how 100% standards compliant Mozilla is, I'm wondering what the philosophy is on extending the standard, if "preload" isn't in some later HTML standard that I don't yet know about us.
This now concludes our broadcast day.
I would turn this off immediatelly even if it works correctly. I have limited bandwidth every month. I only want to load what I need. Not what the server thinks that I need.
Greetings,
Project Manager of Crystal Space (http://www.crystalspace3d.org). Support CS at http://tinyurl.com/cb3x4
It's nice that you mention window managers. Although generally not running on the X server side, they are an integral part of the X window system. Even though window managers are specified as an entity separate from the client application, we've seen lots of innovation in window managers.
;-).
If the X server would not mandate certain widgets, just as it does not mandate any specific window manager, but would simply allow a 'widget server', then client applications could still be relieved of the burden of managing their own widgets, just as clients are already relieved from the burden of drawing their own window decorations and moving windows around.
It would be great if applications wouldn't have to worry about drawing a check mark in check boxes when clicked, not even at the protocol level, and that a widget server would handle that.
We'd change themes (widget servers) as easy as we change window managers now, and have a well-defined protocol between client application, display server and widget server, just as we have for window managers.
I'm serious. We need a better X protocol. And it's not HTML/XML over HTTP, sorry. The ultimate test there is to get self hosting I guess, i.e. can you implement a web browser as a web application.
But until someone implements gecko in javascript, I'm sceptical
All generalizations are false, including this one. (Mark Twain)