[New] Firefox 6 / Thunderbird 6 / Seamonkey 2.3

29 views
Skip to first unread message

Rich Walsh

unread,
Aug 23, 2011, 12:31:53 AM8/23/11
to

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

unread,
Aug 23, 2011, 1:52:12 AM8/23/11
to
Am 23.08.11 06.31, schrieb Rich Walsh:

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

unread,
Aug 23, 2011, 10:34:00 AM8/23/11
to
On the downloads, I figured out with FFv4 that you can't
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

unread,
Aug 23, 2011, 1:50:36 PM8/23/11
to
On 8/23/2011 7:34 AM, Ian Manners wrote:

> you can't download to a drive root, only to a subdirectory.

I have seen this also.

Alex Taylor

unread,
Aug 24, 2011, 6:16:11 AM8/24/11
to
On Tue, 23 Aug 2011 17:50:36 UTC, Steve Wendt <spa...@forgetit.org> wrote:

> > 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

unread,
Aug 24, 2011, 9:56:22 AM8/24/11
to
Şann 23/08/2011 15:34, skrifaği Ian Manners:

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

unread,
Aug 24, 2011, 11:12:33 AM8/24/11
to
On Wed, 24 Aug 2011 14:56:22 +0100, Olafur Gunnlaugsson
<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

unread,
Aug 24, 2011, 1:02:07 PM8/24/11
to
On 8/24/2011 6:56 AM, Olafur Gunnlaugsson 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

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

unread,
Aug 24, 2011, 8:49:08 PM8/24/11
to
Şann 24/08/2011 18:02, skrifaği Steve Wendt:

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

unread,
Aug 24, 2011, 8:57:04 PM8/24/11
to
On 8/24/2011 5:49 PM, Olafur Gunnlaugsson 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
>>

>> 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

unread,
Aug 24, 2011, 9:03:48 PM8/24/11
to
�ann 24/08/2011 16:12, skrifa�i Paul Ratcliffe:

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

unread,
Aug 24, 2011, 9:53:03 PM8/24/11
to
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

> ž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

unread,
Aug 24, 2011, 11:26:21 PM8/24/11
to

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

unread,
Aug 25, 2011, 1:55:41 AM8/25/11
to
On 08/24/11 08:26 pm, Dave Yeo wrote:

>> 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

unread,
Aug 26, 2011, 1:16:28 PM8/26/11
to
Şann 25/08/2011 02:53, skrifaği Steve Wendt:

> 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
>> ş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?

óli.com
Björn.com

Any punicode domain for that matter

Olafur Gunnlaugsson

unread,
Aug 26, 2011, 1:20:07 PM8/26/11
to
Şann 25/08/2011 02:53, skrifaği Steve Wendt:

>> 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

unread,
Aug 26, 2011, 1:22:01 PM8/26/11
to
Şann 25/08/2011 02:53, skrifaği Steve Wendt:
> 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
>> ş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

Notice that there is no com, net, org

com,net, org are not USA domains, they are global domains

Olafur Gunnlaugsson

unread,
Aug 26, 2011, 1:32:28 PM8/26/11
to
Şann 25/08/2011 02:53, skrifaği Steve Wendt:
> 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
>> ş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

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

unread,
Aug 26, 2011, 1:44:02 PM8/26/11
to
On 8/26/2011 10:32 AM, Olafur Gunnlaugsson wrote:

> 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

unread,
Aug 26, 2011, 5:34:58 PM8/26/11
to
Şann 26/08/2011 18:44, skrifaği Steve Wendt:

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

Untitled-1.jpg
Untitled-2.jpg

Dave Yeo

unread,
Aug 26, 2011, 8:55:27 PM8/26/11
to
Olafur Gunnlaugsson wrote:
>> 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

unread,
Aug 27, 2011, 6:20:13 AM8/27/11
to
Şann 27/08/2011 01:55, skrifaği Dave Yeo:

They have done so already it seems since my last couple of posts have
not shown up here ......

KO Myung-Hun

unread,
Aug 28, 2011, 8:18:44 AM8/28/11
to
Hi/2.

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

unread,
Aug 28, 2011, 4:47:47 PM8/28/11
to
On 23.08.11 06.31, Rich Walsh wrote:
>

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

unread,
Aug 28, 2011, 5:01:26 PM8/28/11
to
On Tue, 23 Aug 2011 04:31:53 UTC, "Rich Walsh" <spamyo...@127.0.0.1>
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

unread,
Aug 29, 2011, 4:56:28 AM8/29/11
to
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

Alfredo Fernández Díaz

unread,
Aug 29, 2011, 6:38:46 AM8/29/11
to
Hi,

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

unread,
Aug 29, 2011, 7:17:52 PM8/29/11
to dev-po...@lists.mozilla.org
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?
Dave

KO Myung-Hun

unread,
Aug 31, 2011, 8:46:09 AM8/31/11
to
Hi/2.

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

unread,
Aug 31, 2011, 11:12:05 AM8/31/11
to
KO Myung-Hun wrote:
> 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

unread,
Aug 31, 2011, 1:00:18 PM8/31/11
to
On 8/31/2011 5:46 AM, KO Myung-Hun wrote:

> It seemed that WM_QUERYCONVERTPOS codes were removed at some point.

You should probably file a new bug, referencing the one that Dave mentioned.

KO Myung-Hun

unread,
Sep 3, 2011, 8:17:42 AM9/3/11
to
Reply all
Reply to author
Forward
0 new messages