[New] Firefox 6 / Thunderbird 6 / Seamonkey 2.3
Rich Walsh
We're pleased to announce the release of Firefox 6, Thunderbird 6, and
Seamonkey 2.3.
Firefox
-------
http://releases.mozilla.org/pub/mozilla.org/firefox/releases/6.0/contrib/firefox-6.0.en-US.os2.zip
-or-
ftp://ftp.mozilla.org/pub/firefox/releases/6.0/contrib/firefox-6.0.en-US.os2.zip
Thunderbird
-----------
http://releases.mozilla.org/pub/mozilla.org/thunderbird/releases/6.0/contrib/thunderbird-6.0.en-US.o
s2.zip
-or-
ftp://ftp.mozilla.org/pub/thunderbird/releases/6.0/contrib/thunderbird-6.0.en-US.os2.zip
Seamonkey
---------
http://releases.mozilla.org/pub/mozilla.org/seamonkey/releases/2.3/contrib/seamonkey-2.3.en-US.os2.z
ip
-or-
ftp://ftp.mozilla.org/pub/seamonkey/releases/2.3/contrib/seamonkey-2.3.en-US.os2.zip
Note: the first releases of these apps had a bug that has now been
corrected. If your app's files are dated 2011-08-19, please
obtain the revised version dated 2011-08-21. We apologize for
the inconvenience.
Stability
---------
We believe these releases may be the fastest and most stable versions
yet. However, their stability on SMP systems can be greatly improved
by installing an updated copy of tcpip32.dll created by Steve Levine.
The file, along with details on what it fixes and how to install it,
is available from:
http://e-vertise.com/misc/tcpip32-safe.zip
Support
-------
Community support for all of the Mozilla apps is available through
the newsgroups 'mozilla.dev.ports.os2' or 'comp.os.os2.apps'.
Messages posted to other forums may not be seen by the developers.
Walter Meinl
Rich Walsh
Dave Yeo
Herwig Bauernfeind
Thx for your ongoing efforts.
Unfortunately at least FF6 is still suffering from a problem when saving
downloads. Sometimes the download is saved, sometimes it is not.
I don't see a special pattern yet, but I believe that saving to the
default download folder works, while choosing a different folder results
in the chosen file not being saved (download window does not open, file
is not written).
However, both scenarios are not 100% reproducible, it just happens quite
frequently.
I had problems with downloading files/attachments with all recent
mozillas I tried (TB 3.1.x, FF 4, FF6). FF3.6 does not have that
problem, neither does SM 1.1 ...
Kind regards,
Herwig
Ian Manners
download to a drive root, only to a subdirectory.
I'll see how FFv6 goes over the next 24 hours :-)
Thanks for the builds.
Cheers
Ian Manners
Steve Wendt
> you can't download to a drive root, only to a subdirectory.
I have seen this also.
Alex Taylor
> > you can't download to a drive root, only to a subdirectory.
>
> I have seen this also.
I've also seen it with recent SeaMonkey 2.1 builds. (Haven't tried
2.3 yet.) I haven't reported it because I never seem to be able to
try the latest version (thanks to Rich & Walter et al releasing them
so fast <g>).
--
Alex Taylor
Fukushima, Japan
http://www.socis.ca/~ataylo00
Please take off hat when replying.
Olafur Gunnlaugsson
I think this is by design actually, recent windows and linux versions do
not allow saving to root in their default set-ups for "security" reasons
and I think mozilla code mimics that
Paul Ratcliffe
<oligun...@gmail.com> wrote:
> I think this is by design actually, recent windows and linux versions do
> not allow saving to root in their default set-ups for "security" reasons
> and I think mozilla code mimics that
More bollocks from the nannies. The root is no more or less secure than
any other damned directory. There are some seriously misguided people
writing this stuff.
Steve Wendt
> I think this is by design actually, recent windows and linux versions do
> not allow saving to root in their default set-ups for "security" reasons
> and I think mozilla code mimics that
Not true. On Windows 7, if you try to save to C:\, if it fails the
"security" check, it pops up a dialog, asking if you want to save in
your user folder instead. If you try to save to the root of another
drive (where you have access as the logged in user), it works just fine.
Olafur Gunnlaugsson
Yes that is true if the other drive does no contain any boot files, I
should have written root of bootable drive (not just c:) and other
drives that contain bootup files in case of multiple boot systems
visible by windows but pure data drives/partitions can be written to
root, the problem in win7 is that you only get the warning in some cases
in other cases the you either get an error or a non indicated fail
Steve Wendt
>>> I think this is by design actually, recent windows and linux versions do
>>> not allow saving to root in their default set-ups for "security" reasons
>>> and I think mozilla code mimics that
>>
>> Not true. On Windows 7 ...it works just fine.
>
> Yes that is true if the other drive does no contain any boot files, I
> should have written root of bootable drive (not just c:) and other
> drives that contain bootup files in case of multiple boot systems
> visible by windows but pure data drives/partitions can be written to
In any case, this is an OS/2-specific bug. Has anyone filed it in Bugzilla?
Olafur Gunnlaugsson
Mozilla has been getting a bit weird in this respect recently, if you
fire up the FF bowser that came with ecs 1.2 you will find that if
resolves punicode domains correctly while the current version does not
the stated reason is "security" as they might be used to "hijack" domain
names with similar shape letters eg people might get confused between
�ing.com and ping.com, standard.com and standar�.com. �opinions.com and
eopinons.com, etc, so support for punicode resolving was dropped
The odd thing is that the current FF resolves Cyrillic domains correctly
but that character set has characters that are almost 100% identical to
Roman ones but have different values so are even easier to use in
"hijack" situations
They also dropped gopher support recently, reason, it might be an attack
vector, no exploit has ever used it as an attack vector, they could not
show how it could be used as an attack vector, but could imagine it
being used as such, so gopher code was dropped
Steve Wendt
> Mozilla has been getting a bit weird in this respect recently, if you
> fire up the FF bowser that came with ecs 1.2 you will find that if
> resolves punicode domains correctly while the current version does not
Have some examples?
> the stated reason is "security" as they might be used to "hijack" domain
> names with similar shape letters eg people might get confused between
> žing.com and ping.com, standard.com and standarš.com. éopinions.com and
> eopinons.com, etc, so support for punicode resolving was dropped
http://www.mozilla.org/projects/security/tld-idn-policy-list.html
> The odd thing is that the current FF resolves Cyrillic domains correctly
> but that character set has characters that are almost 100% identical to
> Roman ones but have different values so are even easier to use in
> "hijack" situations
Are you sure that's not because they are in the approved list of TLDs?
Have some examples?
> They also dropped gopher support recently, reason, it might be an attack
> vector, no exploit has ever used it as an attack vector, they could not
> show how it could be used as an attack vector, but could imagine it
> being used as such, so gopher code was dropped
I think the real reasons were that it was unmaintained code, and hardly
anybody runs gopher servers any more (http was supposed to replace it,
after all).
https://bugzilla.mozilla.org/show_bug.cgi?id=388195#c9
Dave Yeo
Probably #573220 could be extended to cover it.
I'd assume we're using the same code path as Windows when it comes to
saving files, so if this is the behaviour of a Windows build I doubt
that it'll get fixed on OS/2 unless someone volunteers to rewrite the
code and maintain it. Shortage of manpower and all that and this is
relatively minor.
Dave
Steve Wendt
>> In any case, this is an OS/2-specific bug. Has anyone filed it in
>> Bugzilla?
>
> Probably #573220 could be extended to cover it.
Ah, I'd forgotten about that one.
> so if this is the behaviour of a Windows build
It is not.
Olafur Gunnlaugsson
> On 8/24/2011 6:03 PM, Olafur Gunnlaugsson wrote:
>
>> Mozilla has been getting a bit weird in this respect recently, if you
>> fire up the FF bowser that came with ecs 1.2 you will find that if
>> resolves punicode domains correctly while the current version does not
>
> Have some examples?
>
>> the stated reason is "security" as they might be used to "hijack" domain
>> names with similar shape letters eg people might get confused between
>> eopinons.com, etc, so support for punicode resolving was dropped
>
> http://www.mozilla.org/projects/security/tld-idn-policy-list.html
>
>> The odd thing is that the current FF resolves Cyrillic domains correctly
>> but that character set has characters that are almost 100% identical to
>> Roman ones but have different values so are even easier to use in
>> "hijack" situations
>
> Are you sure that's not because they are in the approved list of TLDs?
> Have some examples?
óli.com
Björn.com
Any punicode domain for that matter
Olafur Gunnlaugsson
>> They also dropped gopher support recently, reason, it might be an attack
>> vector, no exploit has ever used it as an attack vector, they could not
>> show how it could be used as an attack vector, but could imagine it
>> being used as such, so gopher code was dropped
>
> I think the real reasons were that it was unmaintained code, and hardly
> anybody runs gopher servers any more (http was supposed to replace it,
> after all).
> https://bugzilla.mozilla.org/show_bug.cgi?id=388195#c9
That may well be, but the reason given was nonetheless security, which
sounds odd, and http was not meant to replace gopher, they were parallel
developments, gopher more advanced in its day than the web but failed
due to a licensing muddle by original developer, had support for global
indexing for instance (i.e. global search, which we did not get until
Altavista on the web)
Olafur Gunnlaugsson
>
>> Mozilla has been getting a bit weird in this respect recently, if you
>> fire up the FF bowser that came with ecs 1.2 you will find that if
>> resolves punicode domains correctly while the current version does not
>
> Have some examples?
>
>> the stated reason is "security" as they might be used to "hijack" domain
>> names with similar shape letters eg people might get confused between
>> eopinons.com, etc, so support for punicode resolving was dropped
>
> http://www.mozilla.org/projects/security/tld-idn-policy-list.html
Notice that there is no com, net, org
com,net, org are not USA domains, they are global domains
Olafur Gunnlaugsson
>
>> Mozilla has been getting a bit weird in this respect recently, if you
>> fire up the FF bowser that came with ecs 1.2 you will find that if
>> resolves punicode domains correctly while the current version does not
>
> Have some examples?
>
>> the stated reason is "security" as they might be used to "hijack" domain
>> names with similar shape letters eg people might get confused between
>> eopinons.com, etc, so support for punicode resolving was dropped
>
> http://www.mozilla.org/projects/security/tld-idn-policy-list.html
And if you read that document to the end they state like I said that
"the spoofing problem" is the reason they do not support punicode
globally and also state that ICANN got it basically wrong by allowing
the use of punicode on global idn's
The problem with that is that all research on it shows that people are
more likely to notice anisótropic.com than anistoropic.com as a
misspelling of anisotropic.com, so mozilla policy based on the feelings
of someone rather than confirmation to standards or scientific research
I thought Mozilla was the standards based product, but notice that IE 8
and 9 follow actual web standards better than anything coming from Moz
Notice also that they will only allow specific characters for specific
idn's
Steve Wendt
> I thought Mozilla was the standards based product, but notice that IE 8
> and 9 follow actual web standards better than anything coming from Moz
Both of your examples display the exact same punycode in the URL in both
IE9 and SM 2.3.
Olafur Gunnlaugsson
SM 2.3 is not a Mozilla project, Firefox is, and I am not running it so
I cannot possibly comment
óli.com resolves as óli.com in IE9, xn--li-4ja.com in Firefox 6 and 7,
see attachments
IE9 = untitled-1.jpg
Firefox 7 = untitled-2.jpg
Dave Yeo
>> http://www.mozilla.org/projects/security/tld-idn-policy-list.html
>
> Notice that there is no com, net, org
>
> com,net, org are not USA domains, they are global domains
The Americans disagree and will take away your .com,.net and .org domain
really quick if you link to something they don't like.
Dave
Olafur Gunnlaugsson
They have done so already it seems since my last couple of posts have
not shown up here ......
KO Myung-Hun
I've upgraded to SeaMonkey 2.3. from SeaMonkey 2.0.x.
First of all, thanks for your efforts to support SeaMonkey.
By the way, I've found the one fault as a DBCS user.
A DBCS user needs IME to input DBCS chars, at least up to 2.0.x, I could
input DBCS chars in 'over the spot' style. That is, I could see input
box of the combining DBCS chars at the place where a cursor(caret) is.
But on 2.3, the input box is always placed at bottom-left corner of screen.
The way processing WM_QUERYCONVERTPOS message, seems to be changed.
What's the problem ?
--
KO Myung-Hun
Using Mozilla SeaMonkey 2.3
Under OS/2 Warp 4 for Korean with FixPak #15
On AMD ThunderBird 1GHz with 512 MB RAM
Korean OS/2 User Community : http://www.ecomstation.co.kr
mozilla_test
>
hello rich,
> We believe these releases may be the fastest and most stable versions
it feels again faster compared to 2.1 releases. Thanks to the OS/2
Mozilla Team. Now Testing with
Mozilla/5.0 (OS/2; Warp 4.5; rv:6.0) Gecko/20110821 SeaMonkey/2.3
it still crashes on print in case no printer is installed, trp file is
present.
--
cheers
mozilla_test
Mr. G
wrote:
>
> We're pleased to announce the release of Firefox 6, Thunderbird 6, and
> Seamonkey 2.3.
>
> We believe these releases may be the fastest and most stable versions
> yet. However, their stability on SMP systems can be greatly improved
> by installing an updated copy of tcpip32.dll created by Steve Levine.
> The file, along with details on what it fixes and how to install it,
> is available from:
> http://e-vertise.com/misc/tcpip32-safe.zip
>
>
> Walter Meinl
> Rich Walsh
> Dave Yeo
>
First, thanks for the continued updates and support
for FF, SM, & TB.
However, just to let you know, I experienced the
focus problem in FF6.
In a craigslist ad, I highlighted some text, did a Ctrl+C copy,
then clicked on the search bar to paste and no focus. Regained
focus with one of the workarounds. Of course, this is not
reproducable on demand. Always been hit and miss.
Yes, I'm using the 8-21 drop and the updated tcpip32.dll
on an SMP system.
Thanks for reading.
Alex Taylor
> By the way, I've found the one fault as a DBCS user.
>
> A DBCS user needs IME to input DBCS chars, at least up to 2.0.x, I could
> input DBCS chars in 'over the spot' style. That is, I could see input
> box of the combining DBCS chars at the place where a cursor(caret) is.
> But on 2.3, the input box is always placed at bottom-left corner of
> screen.
>
> The way processing WM_QUERYCONVERTPOS message, seems to be changed.
FWIW, I can confirm the same behaviour under Japanese using:
Gecko/20110721 SeaMonkey/2.1
Alfredo Fernández Díaz
Alex Taylor wrote:
> On Sun, 28 Aug 2011 12:18:44 UTC, KO Myung-Hun<ko...@chollian.net> wrote:
>
>> By the way, I've found the one fault as a DBCS user.
>>
>> A DBCS user needs IME to input DBCS chars, at least up to 2.0.x, I could
>> input DBCS chars in 'over the spot' style. That is, I could see input
>> box of the combining DBCS chars at the place where a cursor(caret) is.
>> But on 2.3, the input box is always placed at bottom-left corner of
>> screen.
>>
>> The way processing WM_QUERYCONVERTPOS message, seems to be changed.
>
> FWIW, I can confirm the same behaviour under Japanese using:
> Gecko/20110721 SeaMonkey/2.1
Tested here in a virtual machine; I can confirm the issue with Japanese.
Maybe it's because of the DIVE stuff?
Dave Yeo
> The way processing WM_QUERYCONVERTPOS message, seems to be changed.
Grepping the source I can't find any instances of WM_QUERYCONVERTPOS.
Any idea of what else to search for?
Dave
KO Myung-Hun
Oooops... I can now understand the behavior of SeaMonkey for IME. It's
the default action of PM.
It seemed that WM_QUERYCONVERTPOS codes were removed at some point.
Maybe, SeaMonkey 2.1.x branches.
You should look into SeaMonkey 2.0.x branches first to solve this problem,
Thanks for your consideration.
Dave Yeo
> Hi/2.
>
> Dave Yeo wrote:
>> On 08/28/11 05:18 am, KO Myung-Hun wrote:
>>> The way processing WM_QUERYCONVERTPOS message, seems to be changed.
>>
>> Grepping the source I can't find any instances of WM_QUERYCONVERTPOS.
>> Any idea of what else to search for?
>
> Oooops... I can now understand the behavior of SeaMonkey for IME. It's
> the default action of PM.
>
> It seemed that WM_QUERYCONVERTPOS codes were removed at some point.
> Maybe, SeaMonkey 2.1.x branches.
Seems to have been removed as part of the widget cleanup, here,
https://bugzilla.mozilla.org/show_bug.cgi?id=522896#c33 though it's
strange it wasn't missed sooner.
Dave
Steve Wendt
> It seemed that WM_QUERYCONVERTPOS codes were removed at some point.
You should probably file a new bug, referencing the one that Dave mentioned.