what's new with mozilla 0.9.8
Dawn Endico
0.9.8 release notes. Let me know if you have any
corrections or additions.
* Hebrew is now supported on Solaris. Hebrew and Arabic now
supported on Macintosh systems that have the proper language pack
installed. Pasting is busted (Bug 119877) and there here are still some
open issues related to keyboard input and UI fonts. (Bugs 119860,
119882, 120048, 120334, 121126)
* Thanks to the new nsiTheme API, the classic theme now has native
looking widgets on MacOS X and Windows XP.
* You can now print the contents of an entire address book.
* In the address book, importing txt, tab, csv and ldif now works,
as well as exporting to txt tab and csv.
* Address book now has quick search.
* Mozilla now supports MNG again.
* Dom Inspector is now included on Macintosh builds.
* Dynamic theme switching works again. You can switch themes
without restarting the browser. (Usually)
* Mozilla no longer reads /favicon.ico images by default although
Mozilla still reads page icons defined with the <link> tag. Set the
following pref to turn the feature back on.
user_pref("browser.chrome.favicons",true);
Juan A. Tamad
- Platform Specific
- platform specific issues/bugs/features go here
- Non-platform Specific
- non-platform specific issues/bugs/features go here
- New and Fully Working
- new features or newly exposed features with no open or critical or blocker
bugs open on date of release
- New and Partially Working
- new features but not yet turned by default or not yet exposed and/or has
critical or blocker bugs associated
- Parity
- features/bug/issues to bring Mozilla in parity with IE/NS/etc...
and please include bug numbers when applicable(so the reader can read bugzilla
for the details). I think someone can go through
http://www.mozillazine.org/build_comments/ and try to scour the most visible
bugs/features/issues in the users'/testers' perspective and see if there were
any improvements along these lines.
--
Roderick Lazaro :)
"Debug is human, de-fix divine."
Mark Dixon
>
> * Mozilla no longer reads /favicon.ico images by default although
> Mozilla still reads page icons defined with the <link> tag. Set the
> following pref to turn the feature back on.
>
> user_pref("browser.chrome.favicons",true);
Why did this go by default? Is a neat feature.
Mark
Jonas Jørgensen
>> * Mozilla no longer reads /favicon.ico images by default although
>> Mozilla still reads page icons defined with the <link> tag. Set the
>> following pref to turn the feature back on.
>>
>> user_pref("browser.chrome.favicons",true);
>
> Why did this go by default?
Because there are too many bugs in Mozilla's implementation of it. It
will (unfortunately) come back when they are fixed.
> Is a neat feature.
<link rel="shortcut icon" href="some-icon.ico"> is a neat feature.
Automatic fetching of favicon.ico is not. I'm too lazy to explain the
reasons here, but there's some threads in n.p.m.browser or ..m.general
about it that you can read.
--
Disclaimer: This disclaimer is not required by my employer.
This article does not necessarily represent the opinions of my employer.
This article does not necessarily disagree with my employer either.
Have a nice day!
Hasbullah Bin Pit (sebol)
> Mark Dixon wrote:
>
> <link rel="shortcut icon" href="some-icon.ico"> is a neat feature.
> Automatic fetching of favicon.ico is not. I'm too lazy to explain the
> reasons here, but there's some threads in n.p.m.browser or ..m.general
> about it that you can read.
galeon is also like that too
the link rel favicon is enable by default
but the favicon.ico is not enable by default
to enable it there are hidden prefs like mozilla
--
Hasbullah Bin Pit (sebol)
Fail signature.txt ini mengandungi enam belas aksara 'a'
dan lapan aksara 'i'
Daniel Veditz
>>Mozilla still reads page icons defined with the <link> tag. Set the
>>following pref to turn the feature back on.
>>
>> user_pref("browser.chrome.favicons",true);
>
> Why did this go by default? Is a neat feature.
The developer got tired of the controversy and turned it off so he could get
on with his life.
-Dan Veditz
Christian Biesinger
[/favicon.ico]
> The developer got tired of the controversy and turned it off so he could get
> on with his life.
No, he (hyatt) said he turned it off because of the bugs in the
implementation.
--
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
-- Benjamin Franklin
Christian Biesinger
> * Mozilla no longer reads /favicon.ico images by default although
> Mozilla still reads page icons defined with the <link> tag. Set the
> following pref to turn the feature back on.
>
> user_pref("browser.chrome.favicons",true);
Can't Edit/Preferences/Appearance/Show Web Site Icons be used instead of
changing prefs.js?
Sören Kuklau
> Dawn Endico wrote:
>
>> * Mozilla no longer reads /favicon.ico images by default although
>> Mozilla still reads page icons defined with the <link> tag. Set the
>> following pref to turn the feature back on.
>>
>> user_pref("browser.chrome.favicons",true);
>
>
> Can't Edit/Preferences/Appearance/Show Web Site Icons be used instead of
> changing prefs.js?
No.
Edit | Preferences | Appearance | Show Web Site Icons toggles
pref("browser.chrome.site_icons", true);
which is on by default. This is for those icons linked to through <link>.
pref("browser.chrome.favicons", false);
though, e.g. the controversial favicon.ico auto-fetching, is off by
default and can be turned back on using the method Mr. Endico described.
In short: "Web Site Icons" => browser.chrome.site_icons
"FavIcons" (auto-fetch, controversial) => browser.chrome.favicons
--
Regards,
Sören Kuklau ('Chucker')
chu...@web.de
Gervase Markham
> default and can be turned back on using the method Mr. Endico described.
Ms. Endico :-)
Gerv
Albert
Couldn't there be a UI pref somewhere for the auto favicon in the
future, so people in the know can turn it off?
--
Albert
"We must have a better word than 'prefabricated'. Why not 'ready-made'?"
--Winston Churchill
If sending email, remove the obvious spam-preventer from my email address.
DeMoN LaG
news:Xns91AC6C0F0...@204.29.187.156, on 04 Feb 2002:
> That would be highly desirable!
41 words in the intro, 5 words in the body. Not a math wiz, but that's
between 85% and 90% of the post being nothing but text to scroll past to
see what you wanted to say. What text goes in when you quote is similar
to a signature. You can have one, but you shouldn't make it a novel.
But you could be worse. You could be one of those people who adds a
trillion
X-Dog: Yes
X-Cat: No
X-Fish: Gold
X-I-Am-An-Asshole: Yes
things to their headers. Seen whole newsgroups of people like that,
each of them having about 60 lines of headers to scroll through to read
their posts. Could you maybe just trim it down, to two lines instead of
4?
--
ICQ: N/A (temporarily)
AIM: FlyersR1 9
email: de_on-lag@ho_e.co_
_ = m
Matthew Thomas
>...
> Couldn't there be a UI pref somewhere for the auto favicon in the
> future, so people in the know can turn it off?
No, because it's Webmasters who need to be able to specify whether or
not their sites have icons, not users. And allowing Webmasters to tweak
your prefs remotely would be a security hazard.
--
Matthew `mpt' Thomas, Mozilla UI Design component default assignee thing
<http://mpt.phrasewise.com/>
DeMoN LaG
> This is about people being in control over what their browser does
> - When I'm viewing a website I do not want to be dictated-to by
> some jumped-up webmaster!
Edit, Preferences, Appearance, [ ] Show web site icons (uncheck box)
Matthew Thomas
>...
> *I* don't want to download *anything* that I do not actually choose to
> download.
>
> If I set Mozilla to not load images, then I don't want it grabbing a
> "favicon" - because I DON'T want it grabbing ANY - savvy?? - *ANY*
> image.
>...
That's a good point. Please file a bug that site icons should not be
loaded when images in general are turned off.
Jonas Jørgensen
> Glenn Miller wrote:
>>...
>> *I* don't want to download *anything* that I do not actually choose to
>> download.
>>
>> If I set Mozilla to not load images, then I don't want it grabbing a
>> "favicon" - because I DON'T want it grabbing ANY - savvy?? - *ANY*
>> image.
>>...
>
> That's a good point. Please file a bug that site icons should not be
> loaded when images in general are turned off.
Why? You can turn off Show Web Site Icons from Appearance.
--
Hvis svaret er Anders Fogh så er spørgsmålet dumt.
Sören Kuklau
> Matthew Thomas wrote:
>> Glenn Miller wrote:
>>> ...
>>> *I* don't want to download *anything* that I do not actually choose to
>>> download.
>>>
>>> If I set Mozilla to not load images, then I don't want it grabbing a
>>> "favicon" - because I DON'T want it grabbing ANY - savvy?? - *ANY*
>>> image.
>>> ...
>> That's a good point. Please file a bug that site icons should not be
>> loaded when images in general are turned off.
> Why? You can turn off Show Web Site Icons from Appearance.
Yup. And icons are _not_ images, by my definition. They're pictures. ;-)
No seriously, I think these settings should be independent.
Peter Trudelle
> Matthew Thomas wrote:
>
>> ...site icons should not be loaded when images in general are turned
>> off.
>
>
> Why? You can turn off Show Web Site Icons from Appearance.
Right. Making such a change would alter the meaning of the pref itself,
since it clearly says "Specify how <program> handles *images on web
pages*". An icon in the URL bar or tab is not an image on a web page by
any stretch. If we started down that road, we'd have to turn off all
icons in the rest of the chrome.
BTW, why is this panel not in the Navigator or perhaps Appearance
section? I had trouble finding the pref, since it never occured to me
that Images would be in Privacy and Security. What is the assocation there?
Peter
Steve Morse
pref for turning them off for selected sites, and why that is considered
a privacy issue.
-- Steve
fantasai
>
> That sounds like strictly a programmer/techie viewpoint, I doubt more than a
> handful of users think that way. I thought image disabling originated from
> the desire to speed up page display over slow connections.
I was actually discussing this with a friend a few hours ago--she was telling
me how much trouble she had finding the pref in NS6.2.
Gervase Markham
> than a handful of users think that way. I thought image disabling
> originated from the desire to speed up page display over slow connections.
Then surely it should disable favicons? With a graphic that small, the
delay will be in the TCP negotiation rather than the time it takes to
send the data, but it's still potentially significant.
And if it says "in web pages" in the Preferences dialog, we can just
change it.
Gerv
Peter Trudelle
> Then surely it should disable favicons? With a graphic that small, the
> delay will be in the TCP negotiation rather than the time it takes to
> send the data, but it's still potentially significant.
AFAIK, nobody has claimed that they even notice the time it takes, let
alone have measured it and found it significant. It isn't as if the
browser could only fetch one thing at a time, and does nothing while the
server responds with the icon, and how long does the TCP handshake take,
anyway? Considering how infrequently it fetches the icon, and what a
tiny percentage of the data it represents, I think this is a non-issue.
Some mozilla contributors seem to not like the idea of it, but I expect
most users and webmasters to appreciate the way it makes their web sites
stand out.
> And if it says "in web pages" in the Preferences dialog, we can just
> change it.
Why? That is a long-standing pref, and there is already a separate pref
for the favicons.
Peter
DeMoN LaG
> If it came from a server, and is not an installed part of Mozilla,
> but rather something that changes according to what page is being
> displayed, then it is certainly an image that is a part of said
> page - and the on/off preference controling this image from a
> website should be located with the preferences for all images on a
> website.
>
> To me the logic of this is self-evident.
I don't think it really matters how self-evident the logic is to you.
It makes no sense to me. Disabling images is for people with slow
connections to not get loaded down with images. Icons are extremely
tiny, and take no noticeable time to download, and don't hog the
connection doing so. I see nothing wrong with how it's done now
Peter Trudelle
>
>If it came from a server, and is not an installed part of Mozilla, but
>rather something that changes according to what page is being displayed,
>then it is certainly an image that is a part of said page - and the on/off
>preference controling this image from a website should be located with the
>preferences for all images on a website.
>
It clearly isn't part of the page, since it isn't displayed there and
changes with the site, but I don' thave any problem with the pref being
in the Images pane, if that's the point you're making.
Peter
Christian Biesinger
[favicon]
> It clearly isn't part of the page, since it isn't displayed there and
> changes with the site,
It can just as well change with the page, there just needs to be a
different <link rel="icon" ...> tag there.
Matthew Thomas
>
> Jonas Jørgensen wrote:
> > Why? You can turn off Show Web Site Icons from Appearance.
>
> Right. Making such a change would alter the meaning of the pref
> itself, since it clearly says "Specify how <program> handles *images
> on web pages*".
That's just bad writing. Firstly, prefs UI should never say `Specify
{whatever}', because you don't have to do that in order to continue
using the program (you can click Cancel, or go to another category).
Secondly, the pref does *not* apply just to Web pages -- it also applies
to e-mail and newsgroup messages, at least.
> BTW, why is this panel not in the Navigator or perhaps Appearance
> section?
>...
Two reasons. Firstly, because the module owner is under the mistaken
impression that turning images off is `blocking' them, rather than
turning them off. (See `option to load blocked images selectively'
<http://bugzilla.mozilla.org/show_bug.cgi?id=101058>.) Therefore, images
on/off ends up in Privacy & Security, along with image blocking, even
though they're separate issues.
Secondly, because Privacy & Security is a black hole, sucking prefs into
its void from all directions. (See `image animations prefs in wrong
place' <http://bugzilla.mozilla.org/show_bug.cgi?id=90837>.) Half the
panels in the Privacy & Security branch should be somewhere else, and
the other half shouldn't exist.
DeMoN LaG
news:3C683B89...@myrealbox.com, on 11 Feb 2002:
> Secondly, because Privacy & Security is a black hole, sucking prefs
> into its void from all directions. (See `image animations prefs in
> wrong place' <http://bugzilla.mozilla.org/show_bug.cgi?id=90837>.)
> Half the panels in the Privacy & Security branch should be
> somewhere else, and the other half shouldn't exist.
I dunno about that now. A lot of stuff in there is misplaced, yes, but
I don't think the panel should just not exist at all. Forms, passwords,
cookies, SSL, certs, etc. They belong *somewhere*, and I think Privacy
and Security seems like a nice name for them collectively
Matthew Thomas
> > Secondly, because Privacy & Security is a black hole, sucking prefs
> > into its void from all directions. (See `image animations prefs in
> > wrong place' <http://bugzilla.mozilla.org/show_bug.cgi?id=90837>.)
> > Half the panels in the Privacy & Security branch should be
> > somewhere else, and the other half shouldn't exist.
>
> I dunno about that now. A lot of stuff in there is misplaced, yes,
> but I don't think the panel should just not exist at all. Forms,
A panel which is only one third full, making it look daft.
> passwords,
Similarly, apart from text which is too long to read, this panel
contains only three controls. The first is legitimate, and could fit on
a single `Web Forms' panel which also held your forms data (replacing
the current massively overblown Forms Manager). The second control is
just a cross reference to another window. The third is a checkbox
masquerading as a pair of option buttons, something which would be worth
filing a bug on were it not for the fact that the `feature' in question
is so meaninglessly technical that no-one will try to use it anyway.
> cookies,
This UI is far too complicated. The bit about `privacy levels' is
particularly bad. Firstly, it uses far too much text. Secondly, it
offers `levels' which are useless because it doesn't explain what they
do. (Yes, those two points are in conflict, and getting rid of the UI
might not be the only solution, but it's the only one I can think of.)
And thirdly, it relies on Web sites to tell the browser whether or not
they have your consent to to collect information about you -- but if you
trust Web sites to be honest about stuff like what they use cookies for,
why the @#$%&! are you wanting to block any cookies in the first place?
> SSL,
Never in the field of Web browsers has so much been shown so
incomprehensibly for the benefit of so few users.
> certs,
The security certificates UI, along with the Forms Manager, would
comprise the top two usability problems in Mozilla -- were it not for
the fact that their design accidentally manages to discourage people
from trying to use them in the first place.
> etc. They belong *somewhere*, and I
> think Privacy and Security seems like a nice name for them
> collectively
>...
They wouldn't need a collective name, if they were in two panels
(`Privacy' and `Security') instead of nine.
John Moore
Marco Moock
> Some 20yrs later this post is useful ... thank you.