Re: Syncing SM bookmarks

[Andrey ``Bass'' Shcheglov]

Hi Bill,

I suppose you've been using the Sync 1.1 server hosted by Mozilla
Foundation.

You can, however, build and run your own one, provided you can guarantee
24x7 availability.

This is what PaleMoon devs do (you can actually switch to using their
Sync 1.1 server).

Regards,
Andrey.

On 03.04.2018 15:44, Bill Spikowski wrote:
> Andrey ``Bass'' Shcheglov wrote:
>> Run your own Sync 1.1 server:
>>
>> <https://mozilla-services.readthedocs.io/en/latest/howtos/run-sync.html>
>>
> 
> I thought Sync 1.1 was what I had been using, until it stopped working a
> couple of years ago.
> 
> Is your link about some version of 1.1 that will still work with Seamonkey?
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: Syncing SM bookmarks

[Andrey ``Bass'' Shcheglov]

Run your own Sync 1.1 server:



Regards,
Andrey.
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Multi-selection not working in message lists

[Andrey ``Bass'' Shcheglov]

Hello,

I have Alt instead of Ctrl set as the default accelerator as described
in :

> user_pref("ui.key.accelKey", 18);
> user_pref("ui.key.menuAccessKey", 0);

This is the behavior Netscape 4.x used to have on Unices.

Surprisingly, starting with version 2.46, I'm no longer able to select
multiple mail/news messages with Ctrl key pressed (to be able to do so
in 2.46+, I have to revert ui.key.accelKey and ui.key.menuAccessKey to
their default values).

Version 2.40 was the last one not affected by this regression.

Is this a known problem?

Regards,
Andrey.
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: Expired certificates in the Builtin Object Token

[Andrey ``Bass'' Shcheglov]

Thanks Lee.

Regards,
Andrey.
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Expired certificates in the Builtin Object Token

[Andrey ``Bass'' Shcheglov]

Hello,

I see a number of expired certificates under Builtin Object Token
(vanilla SeaMonkey 2.46 and 2.49.1, fresh user profile):

https://habrastorage.org/webt/5d/ay/ch/5daychmswvrkawglzjk68bp7vfa.png

If I delete those, they reappear under the "Others" tab:

https://habrastorage.org/webt/xa/2q/is/xa2qisg6arve5xwmc6tmpcmwrqw.png

The certificates are expired (expiration year is 2014, below is an
example for https://addons.mozilla.org):

https://habrastorage.org/webt/5f/ry/ox/5fryoxyqavfrl6hcibhnsbzjxuw.png

They, naturally, differ from their effective counterparts of the said
web sites:

https://habrastorage.org/webt/rs/rq/we/rsrqwev0r-wnaujxrpacyf-s0s4.png

What's the need for those?

Regards,
Andrey.
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Unable to download any files when browser.download.useDownloadDir is false

[Andrey ``Bass'' Shcheglov]

Hello,

I'm running

Mozilla/5.0 (X11; Linux x86_64; rv:49.0) Gecko/20100101 Firefox/49.0 
SeaMonkey/2.46


(build identifier 20161213175921) under Debian Linux 9 (Stretch) amd64.

I'm using the contributed 64-bit GTK2 build of SeaMonkey 
(https://archive.mozilla.org/pub/seamonkey/releases/2.46/contrib/seamonkey-2.46.en-US.linux-x86_64.tar.bz2) 
with the following build config:



Source

Built from 
http://hg.mozilla.org/releases/comm-release/rev/6fe0f5662a084ff3d6cc0a69a00490c0910b3b35


Build platform

target x86_64-pc-linux-gnu

Build tools

Compiler
Version
Compiler flags

/usr/bin/ccache /builds/slave/rel-c-rel-lnx64-bld/build/gcc/bin/gcc 
-std=gnu99

4.8.5
-Wall -Wempty-body -Wignored-qualifiers -Wpointer-arith -Wsign-compare 
-Wtype-limits -Wunreachable-code -Wno-error=maybe-uninitialized 
-Wno-error=deprecated-declarations -Wno-error=array-bounds 
-fno-strict-aliasing -ffunction-sections -fdata-sections 
-fno-math-errno -pthread -pipe


/usr/bin/ccache /builds/slave/rel-c-rel-lnx64-bld/build/gcc/bin/g++ 
-std=gnu++11

4.8.5
-Wall -Wc++11-compat -Wempty-body -Wignored-qualifiers 
-Woverloaded-virtual -Wpointer-arith -Wsign-compare -Wtype-limits 
-Wunreachable-code -Wwrite-strings -Wno-invalid-offsetof 
-Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations 
-Wno-error=array-bounds -fno-exceptions -fno-strict-aliasing -fno-rtti 
-ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno 
-pthread -D_GLIBCXX_USE_CXX11_ABI=0 -pipe -g -freorder-blocks -Os 
-fomit-frame-pointer


Configure options

--enable-application=suite 
--with-external-source-dir=/builds/slave/rel-c-rel-lnx64-bld/build 
--enable-update-channel=release --enable-js-shell 
--enable-default-toolkit=cairo-gtk2 --with-ccache=/usr/bin/ccache 
CC=/builds/slave/rel-c-rel-lnx64-bld/build/gcc/bin/gcc 
CXX=/builds/slave/rel-c-rel-lnx64-bld/build/gcc/bin/g++ 
--enable-crashreporter --enable-elf-hack --enable-release 
--enable-stdcxx-compat


I have the following preferences set related to downloads:


browser.download.dir=/home/bass
browser.download.folderList=2
browser.download.lastDir=/home/bass
browser.download.manager.behavior=1
browser.download.progress.closeWhenDone=true
browser.download.useDownloadDir=false


Whenever I try to download a file or an e-mail attachment (either by 
following a link to the file or via "Save Link Target As..." or even via 
File -> "Save Page As..." for HTML files), nothing happens (the file 
selection dialog never pops up, the download history in the Download 
Manager remains empty), and the downloaded files remain sitting (with 
the ".part" extension) under /tmp/mozilla_bass0 (I wonder what's the 
need of using my TMPDIR here, as my /tmp slice may not even be large 
enough to contain the downloaded file).


If I flip the useDownloadDir property 
(browser.download.useDownloadDir=true), which corresponds to "save file 
to the configured location", downloads become functional again, except 
that I'm no longer able to specify the download location.


I don't have any add-ons installed, so restarting in safe mode doesn't 
make any difference.


On the other hand, the issue is only reproducible for my own profile and 
not for a newly created one.



How can I further diagnose the problem?

Are there any caches I can try to re-set?


Regards,
Andrey.


___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: 8-bit MIME vs quoted-printable for signed messages

[Andrey ``Bass'' Shcheglov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Thank you.

Just found that both Sylpheed and Claws-Mail do exactly the same for
signed messages, even if transfer encoding is set to "8 bit".

Regards,
Andrey.

On 25.09.2017 14:06, chokito wrote:
> I have found this on https://www.cryptosys.net/pki/manpki/pki_usinginm
ime.html: "You are strongly recommended to use quoted-printable encoding
 for the content part of the message to prevent the signed data being ch
anged during transmission."
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iEYEARECAAYFAlnI9BgACgkQFX2weoTrDGfvcgCdGd+LsCTlmNkLscN/pS9XgojL
Y14AoOiEA8CohdHXxiVItYFD1nNa+5+d
=N5ui
-END PGP SIGNATURE-
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: 8-bit MIME vs quoted-printable for signed messages

[Andrey ``Bass'' Shcheglov]

In my original message, I was asking about S/MIME signed messages.

S/MIME encrypted messages is a separate matter: your message body is
never transmitted in plain text, nor is quoted-printable encoding used.

The "smime.p7m" MIME part is actually a base64-encoded binary file which
represents the encrypted message body.

Regards,
Andrey.

On 22.09.2017 16:09, chokito wrote:
> Settings: default values
> mail.strictly_mime;false
> mail.strictly_mime.parm_folding;1
> mail.strictly_mime_headers;true
> 
> Received header:
> ---
> MIME-Version: 1.0
> Content-Type: application/pkcs7-mime; name="smime.p7m"; 
> smime-type=enveloped-data
> Content-Transfer-Encoding: base64
> Content-Disposition: attachment; filename="smime.p7m"
> Content-Description: S/MIME Encrypted Message
> 
> SeaMonkey 2.49.1 ( 20170619162041)
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

8-bit MIME vs quoted-printable for signed messages

[Andrey ``Bass'' Shcheglov]

Hello,

SeaMonkey Mail has a flag to turn MIME Quoted-Printable on
(mail.strictly_mime=true), or use the 8-bit MIME for non-ASCII
characters instead (mail.strictly_mime=false, the default).

8-bit MIME support works fine as long as I use plain-text messages:

> MIME-Version: 1.0
> Content-Type: text/plain; charset=KOI8-R
> Content-Transfer-Encoding: 8bit

or plain-text messages with attachments:

> MIME-Version: 1.0
> Content-Type: multipart/mixed;
>  boundary="35CC02DE2AE5C262E603123C"
> 
> This is a multi-part message in MIME format.
> --35CC02DE2AE5C262E603123C
> Content-Type: text/plain; charset=KOI8-R
> Content-Transfer-Encoding: 8bit


If, however, I want to send an S/MIME:

> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; 
> micalg=sha-256; boundary="ms090906030006040802020901"

or a PGP/MIME signed message:

> Content-Type: multipart/signed; micalg=pgp-sha1;
>  protocol="application/pgp-signature";
>  boundary="JtS08MAj4iIEUA9NbuVGRLWU7ge3cLOTW"

my message body gets always encoded as quoted-printable:

> Content-Transfer-Encoding: quoted-printable


What is the reason for this behaviour, and how can change it (i. e.
force SeaMonkey to use 8 bit MIME)?


Regards,
Andrey.

___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: Demise of Sync - alternatives?

[Andrey ``Bass'' Shcheglov]

Hello,

Using older SeaMonkey versions (e.g.: 2.7), it was possible to change
services.sync.serverURL  from
https://auth.services.mozilla.com/ to
https://pmsync.palemoon.net/sync/index.php/ and easily link SeaMonkey to
an existing Pale Moon sync account (this is how I sync my Debian IceApe
(rebranded SM 2.7) with Pale Moon).

It doesn't seem possible any more with modern SM versions: when I choose
"I already have a SeaMonkey Sync" account, enter the username, password
and recovery key and press "Next" -- nothing happens (no change of the
UI, no error message, no HTTP(S) packets sent to pmsync.palemoon.net).

It still should be possible to set up Sync (v1.1) by setting some extra
preferences in about:config, omitting the Sync UI, but I have had no
success so far.

Regards,
Andrey.

On 15.07.2017 0:15, Frank-Rainer Grahl wrote:
> Sync 1.5 has not been ported yet and with all the crap going on with Fx
> I am not sure it is a good idea anyway. You need a Firefox account and
> everything is tightly coupled to Mozilla. So no for official sync. You
> could probably still set up your own Sync 1.1 server in 2.46 to 2.49 as
> mentioned but the old 1.1 code has been removed by Mozilla from the
> backend too in the latest nightly releases.
> 
> In the long term we need to provide our own sync servers and make
> something work but for now don't hold your breath.
> 
> FRG
> 
> Saptarshi Roy wrote:
>> On Monday, 12 October 2015 19:31:54 UTC+5:30, Bill Spikowski  wrote:
>>> Sync 1.1 no longer works, as Mozilla has shut down their sync server.
>>>
>>> Is updating Seamonkey to use Mozilla's new sync server something
>>> that's in the works and might be expected soon (say, the next month,
>>> rather than next year or not at all)?
>>>
>>> Thomas Rocek recently posted the instructions for setting up a new
>>> Sync 1.1 server, but they're way beyond my tech abilities. Is anyone
>>> aware of a publicly available Sync 1.1 method that Seamonkey users
>>> could rely on for the duration?
>>
>> Is there a way to create a Seamonkey sync account in the latest build?
>>
> 
> ___
> support-seamonkey mailing list
> support-seamonkey@lists.mozilla.org
> https://lists.mozilla.org/listinfo/support-seamonkey



smime.p7s
Description: S/MIME Cryptographic Signature
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: SeaMonkey Mail: subject not handled properly when a mailto: link is clicked

[Andrey ``Bass'' Shcheglov]

Mark, you've made my day.

Many thanks!

Regards,
Andrey.

On 05.07.2017 22:19, mozilla-lists.mbou...@spamgourmet.com wrote:
> RFC 2368 and RFC 1738 are obsoleted by newer versions. I haven't read
> through all of them in detail, but for what it's worth RFC 6068 (which
> replaces RFC 2368) mentions in section 5:
>Current implementations encode
>a space as '+', but this creates problems because such a '+' standing
>for a space cannot be distinguished from a real '+' in a 'mailto'
>URI.  When producing 'mailto' URIs, all spaces SHOULD be encoded as
>%20, and '+' characters MAY be encoded as %2B.
> So that at least acknowledges that expected handling of a '+' is
> ambiguous, and that anyone producing mailto URIs should encode spaces as
> %20. A quick search of the others didn't turn up any obvious mention of
> encoding spaces as '+'. Were there specific sections where you saw this
> mentioned?
> 
> "application/x-www-form-urlencoded" is a content type used in HTTP POST
> requests, in which the content is in a similar format to URL query
> strings. I'm not sure off the top of my head whether the query part of a
> URI is defined to be exactly the same format as
> "application/x-www-form-urlencoded" content, nor whether the current
> version allows encoding spaces as '+'.
> 
> All in all, if you want consistent behaviour, it's probably best to use
> %20 to represent a space even if some applications also accept '+'.



smime.p7s
Description: S/MIME Cryptographic Signature
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: DSN on Compose Window

[Andrey ``Bass'' Shcheglov]

Hello,

Under about:config, I believe you need to play with the mail.dsn.*
family, particularly with mail.dsn.always_request_on.

Regards,
Andrey.

On 05.07.2017 11:05, ossnorthw...@gmail.com wrote:
> Hi All,
> 
> Is there a way to have DSN [Delivery Status Notification] always selected ie 
> = ON
> so I don't have to select it every time?
> 
> Thanks!
> 
> g:o)
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: Lorem+ipsum+dolor+sit+amet

[Andrey ``Bass'' Shcheglov]

Surely it did,

but the subject should have been

> Lorem ipsum dolor sit amet

not

> Lorem+ipsum+dolor+sit+amet

Regards,
Andrey.

On 04.07.2017 17:16, GérardJan wrote:
> this worked well.
> 
> sincerely,
> 



smime.p7s
Description: S/MIME Cryptographic Signature
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: SeaMonkey Mail: subject not handled properly when a mailto: link is clicked

[Andrey ``Bass'' Shcheglov]

Hello Jonathan,

Thank you for your response.

mailto: links are indeed standard, with Mozilla products (since Netscape
4.x) supporting only part of the standard.

Since the format of the URL is "application/x-www-form-urlencoded", both
+ and %20 should be supported -- see RFC 2368
<https://tools.ietf.org/html/rfc2368>, RFC 1738
<https://tools.ietf.org/html/rfc1738>
 and RFC 3986 <https://tools.ietf.org/html/rfc3986>.

Regards,
Andrey.

On 04.07.2017 16:52, Jonathan N. Little wrote:
> Andrey ``Bass'' Shcheglov wrote:
>> Hello,
>>
>> Whenever I click a mailto: link with a subject, e. g.:
>>
>> <mailto:support-seamonkey@lists.mozilla.org?subject=Lorem+ipsum+dolor+sit+amet>
>>
>>
>> the new message window opens with a non-empty subject, but the plus
>> signs are not replaced with spaces, i. e. I get
>> "Lorem+ipsum+dolor+sit+amet", not "Lorem ipsum dolor sit amet".
>>
>> This is reproducible using
>>> Mozilla/5.0 (X11; Linux i686; rv:49.0) Gecko/20100101 Firefox/49.0
>>> SeaMonkey/2.46
>> and
>>> Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101
>>> Firefox/52.0 SeaMonkey/2.49
>>
>> Is this a known issue?
> 
> I don't know, isn't mailto links not really a standard? Anyway, should
> you not format it URL escaping to get what you want?
> 
> <mailto:support-seamonkey@lists.mozilla.org?subject=Lorem%20ipsum%20dolor%20sit%20amet>
> 
> 
> 
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

SeaMonkey Mail: subject not handled properly when a mailto: link is clicked

[Andrey ``Bass'' Shcheglov]

Hello,

Whenever I click a mailto: link with a subject, e. g.:



the new message window opens with a non-empty subject, but the plus
signs are not replaced with spaces, i. e. I get
"Lorem+ipsum+dolor+sit+amet", not "Lorem ipsum dolor sit amet".

This is reproducible using
> Mozilla/5.0 (X11; Linux i686; rv:49.0) Gecko/20100101 Firefox/49.0
> SeaMonkey/2.46
and
> Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101
> Firefox/52.0 SeaMonkey/2.49

Is this a known issue?

Regards,
Andrey.



___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: Oddity noticed downloading an ISO file

[Andrey ``Bass'' Shcheglov]

Hello Richard,

In addition to setting general.useragent.site_specific_overrides:

> general.useragent.site_specific_overrides=true
> general.useragent.override.sourceforge.net=Wget/1.17.1
> general.useragent.override.downloads.sourceforge.net=Wget/1.17.1

you would need to set network.http.sendRefererHeader to 0 (more on this
here: <http://kb.mozillazine.org/Network.http.sendRefererHeader>).

Regards,
Andrey.

On 04.05.2017 18:27, Andrey ``Bass'' Shcheglov wrote:
> When you follow the "download" URL of a file hosted by SourceForge, it
> gets downloaded in 4 HTTP requests (instead of one):
> 
>> GET https://downloads.sourceforge.net/gparted/gparted-live-0.28.1-1-i686.iso
>> HTTP 307
>>
>> GET 
>> https://sourceforge.net/projects/gparted/files/gparted-live-stable/0.28.1-1/gparted-live-0.28.1-1-i686.iso/download?use_mirror=netcologne
>> HTTP 200
> 
> At this point, you're presented with a SourceForge download page and
> have to stare at their advertisements for like 5 seconds. After which
> the page is refreshed for the 2nd time:
> 
>> GET 
>> https://downloads.sourceforge.net/project/gparted/gparted-live-stable/0.28.1-1/gparted-live-0.28.1-1-i686.iso?r==1493909634_mirror=netix
>> HTTP 302
>>
>> GET 
>> https://netix.dl.sourceforge.net/project/gparted/gparted-live-stable/0.28.1-1/gparted-live-0.28.1-1-i686.iso
>> HTTP 200
> ... and you're finally allowed to download the darn file.
> 
> You can perform the above diagnostics yourself using either the
> "Developer Tools" (the former Firebug), or the 3rd party "Live HTTP
> Headers" extension available at AMO, or by setting the
> accessibility.blockautorefresh preference to true (Appearance -> Content
> -> Warn me when websites try to redirect or reload the page).
> 
> No browser is smart enough to rid you from this five second delay.
> 
> 
> Wget is a different story: apparently, the web server interprets its
> User-Agent string as "something which is not a browser" and skips the
> advertisement page.
> 
> You can try to play with general.useragent.site_specific_overrides as
> described here: <http://forums.mozillazine.org/viewtopic.php?f=40=2647781>
> 
> 
> Regards,
> Andrey.



smime.p7s
Description: S/MIME Cryptographic Signature
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: Oddity noticed downloading an ISO file

[Andrey ``Bass'' Shcheglov]

When you follow the "download" URL of a file hosted by SourceForge, it
gets downloaded in 4 HTTP requests (instead of one):

> GET https://downloads.sourceforge.net/gparted/gparted-live-0.28.1-1-i686.iso
> HTTP 307
> 
> GET 
> https://sourceforge.net/projects/gparted/files/gparted-live-stable/0.28.1-1/gparted-live-0.28.1-1-i686.iso/download?use_mirror=netcologne
> HTTP 200

At this point, you're presented with a SourceForge download page and
have to stare at their advertisements for like 5 seconds. After which
the page is refreshed for the 2nd time:

> GET 
> https://downloads.sourceforge.net/project/gparted/gparted-live-stable/0.28.1-1/gparted-live-0.28.1-1-i686.iso?r==1493909634_mirror=netix
> HTTP 302
> 
> GET 
> https://netix.dl.sourceforge.net/project/gparted/gparted-live-stable/0.28.1-1/gparted-live-0.28.1-1-i686.iso
> HTTP 200
... and you're finally allowed to download the darn file.

You can perform the above diagnostics yourself using either the
"Developer Tools" (the former Firebug), or the 3rd party "Live HTTP
Headers" extension available at AMO, or by setting the
accessibility.blockautorefresh preference to true (Appearance -> Content
-> Warn me when websites try to redirect or reload the page).

No browser is smart enough to rid you from this five second delay.


Wget is a different story: apparently, the web server interprets its
User-Agent string as "something which is not a browser" and skips the
advertisement page.

You can try to play with general.useragent.site_specific_overrides as
described here: <http://forums.mozillazine.org/viewtopic.php?f=40=2647781>


Regards,
Andrey.

On 04.05.2017 17:00, Richard Owlett wrote:
> On 05/04/2017 07:31 AM, Andrey ``Bass'' Shcheglov wrote:
>> Hi Richard,
>>
>> Can you test how wget/curl behave when given the same URL?
>>
>> Regards,
>> Andrey.
>>
> 
> It "ran".
> richard@march-9-Jessie:~/testfolder$ ls -lh
> total 318M
> -rw-r--r-- 1 richard richard  44M May  4 08:22
> gparted-live-0.28.1-1-i686.iso
> -rw-r--r-- 1 richard richard 274M Feb 18 00:20
> gparted-live-0.28.1-1-i686.iso.1
> 
> *HOWEVER*
> richard@march-9-Jessie:~/1st_run$ ls -lh
> total 275M
> -rw-r--r-- 1 richard richard  84K May  4 06:50 download
> -rw-r--r-- 1 richard richard 274M May  4 06:40
> gparted-live-0.28.1-1-i686.iso
> 
> 
> 
> I don't know how to interpret the following.
> 
> richard@march-9-Jessie:~/testfolder$ wget
> http://downloads.sourceforge.net/gparted/gparted-live-0.28.1-1-i686.iso
> --2017-05-04 08:23:12--
> http://downloads.sourceforge.net/gparted/gparted-live-0.28.1-1-i686.iso
> Resolving downloads.sourceforge.net (downloads.sourceforge.net)...
> 216.34.181.59
> Connecting to downloads.sourceforge.net
> (downloads.sourceforge.net)|216.34.181.59|:80... connected.
> HTTP request sent, awaiting response... 301 Moved Permanently
> Location:
> http://downloads.sourceforge.net/project/gparted/gparted-live-stable/0.28.1-1/gparted-live-0.28.1-1-i686.iso
> [following]
> --2017-05-04 08:23:12--
> http://downloads.sourceforge.net/project/gparted/gparted-live-stable/0.28.1-1/gparted-live-0.28.1-1-i686.iso
> 
> Connecting to downloads.sourceforge.net
> (downloads.sourceforge.net)|216.34.181.59|:80... connected.
> HTTP request sent, awaiting response... 302 Found
> Location:
> https://cytranet.dl.sourceforge.net/project/gparted/gparted-live-stable/0.28.1-1/gparted-live-0.28.1-1-i686.iso
> [following]
> --2017-05-04 08:23:12--
> https://cytranet.dl.sourceforge.net/project/gparted/gparted-live-stable/0.28.1-1/gparted-live-0.28.1-1-i686.iso
> 
> Resolving cytranet.dl.sourceforge.net (cytranet.dl.sourceforge.net)...
> 74.82.59.181
> Connecting to cytranet.dl.sourceforge.net
> (cytranet.dl.sourceforge.net)|74.82.59.181|:443... connected.
> HTTP request sent, awaiting response... 200 OK
> Length: 287309824 (274M) [application/octet-stream]
> Saving to: ‘gparted-live-0.28.1-1-i686.iso.1’
> 
> 
> 
> 
> 
> 
> 
>> On Thursday, 4 May 2017, Richard Owlett <rowl...@cloud85.net> wrote:
>>
>>> I'm running SM 2.48 on Debian Jessie
>>> User Agent: Mozilla/5.0 (X11; Linux i686; rv:49.0) Gecko/20100101
>>> Firefox/49.0 SeaMonkey/2.46
>>>
>>> I went to http://gparted.org/download.php and right-clicked on link
>>> titled "Download gparted-live-0.28.1-1-i686.iso" whose target was
>>> http://downloads.sourceforge.net/gparted/gparted-live-0.28.1-1-i686.iso
>>>
>>> When I chose "Save Link Target As" it saved a HTML file named
>>> "download".
>>>
>>> However when I left-clicked on the above link, it took me to
>>> https://s

Re: Oddity noticed downloading an ISO file

[Andrey ``Bass'' Shcheglov]

Hi Richard,

Can you test how wget/curl behave when given the same URL?

Regards,
Andrey.

On Thursday, 4 May 2017, Richard Owlett  wrote:

> I'm running SM 2.48 on Debian Jessie
> User Agent: Mozilla/5.0 (X11; Linux i686; rv:49.0) Gecko/20100101
> Firefox/49.0 SeaMonkey/2.46
>
> I went to http://gparted.org/download.php and right-clicked on link
> titled "Download gparted-live-0.28.1-1-i686.iso" whose target was
> http://downloads.sourceforge.net/gparted/gparted-live-0.28.1-1-i686.iso
>
> When I chose "Save Link Target As" it saved a HTML file named "download".
>
> However when I left-clicked on the above link, it took me to
> https://sourceforge.net/projects/gparted/files/gparted-live-
> stable/0.28.1-1/gparted-live-0.28.1-1-i686.iso/download?use_mirror=iweb
>
> That triggered an automated download of the desired ISO file.
> The content of the save HTML was the sourceforge.net page.
>
> Is this expected behavior?
> TIA
>
>
> ___
> support-seamonkey mailing list
> support-seamonkey@lists.mozilla.org
> https://lists.mozilla.org/listinfo/support-seamonkey
>
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Insert -> Link when composing an e-mail message

[Andrey ``Bass'' Shcheglov]

Hello all,

The shortcut for Insert -> Link... has always been Ctrl+L for both
Mail and Composer.

Now I'm running a pre-release version of SM 2.49 (Mozilla/5.0 (Windows
NT 6.3; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49),
build id 20170314033308, and the shortcut is Ctrl+K instead.

What was the reason for this change?
Can I somehow revert to the old behaviour?

Regards,
Andrey.
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey