Closed Bug 692072 Opened 13 years ago Closed 13 years ago

mailto link doesn't submit target address or other data

Categories

(SeaMonkey :: MailNews: Composition, defect)

x86_64
Linux
defect
Not set
normal

Tracking

(seamonkey2.5 unaffected, seamonkey2.6 affected, seamonkey2.7+ fixed)

RESOLVED DUPLICATE of bug 691288
Tracking Status
seamonkey2.5 --- unaffected
seamonkey2.6 --- affected
seamonkey2.7 + fixed

People

(Reporter: moz, Unassigned)

Details

(Keywords: regression)

Attachments

(3 files)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0a2) Gecko/20111004 Firefox/9.0a2 SeaMonkey/2.6a2
Build ID: 20111004013008

Steps to reproduce:

Follow link with mailto-Protocol and ?subject parameter


Actual results:

SeaMonkey  Mail-Compose-Window without to-Adress or subject is openend 


Expected results:

Mail-Compose-Window should be prefilled with adress and subject from mailto-Link
The error window is

hafi@i5 ~ $ fenster 1109270526-1109280615
2011-09-26 20:26:00 PDT
2011-09-27 21:15:00 PDT

Test case at bottom of <http://sujag.de/kontakt.php>
Please provide a minimized test case. Thanks.
Every poster name on this bug page can be used as a testcase. These are mailto-Links that should result in a Mail-Compose-Window with prefilled to-Field
In reply to comment #2
This is working for me, with SeaMonkey 2.5 Beta 1, both from external programs [Firefox] and with internal SeaMonkey browser.

I'm getting To: filled in and Subject filled with "Question"

Sue can you possibly try with addons disabled?
(In reply to Justin Wood (:Callek) from comment #5)

> This is working for me, with SeaMonkey 2.5 Beta 1, both from external
> programs [Firefox] and with internal SeaMonkey browser.

Which build date? Have you considered the above mentioned error window?

> I'm getting To: filled in and Subject filled with "Question"

So it is with SMs older than 2011-09-26 20:26:00 PDT ;)

> Sue can you possibly try with addons disabled?

safe-mode makes no difference
I see this bug with recent tinderbox builds also. Even with a new profile. No messages in the error console.
(In reply to Hartmut Figge from comment #6)
> (In reply to Justin Wood (:Callek) from comment #5)
> 
> > This is working for me, with SeaMonkey 2.5 Beta 1, both from external
> > programs [Firefox] and with internal SeaMonkey browser.
> 
> Which build date? Have you considered the above mentioned error window?

Build date doesn't matter for me, I'm on the *official* 2.5 Beta 1 when I tested. I also do not get an error window.

> > I'm getting To: filled in and Subject filled with "Question"
> 
> So it is with SMs older than 2011-09-26 20:26:00 PDT ;)

If you in-fact tested on SM 2.6a2 then its actually newer than 2.5 Beta 1, regardless of build date.

> > Sue can you possibly try with addons disabled?
> 
> safe-mode makes no difference

I also tested on win7, fwiw. Not linux64. CC-ing someone who can probably assist more here (in terms of testing).
(In reply to Justin Wood (:Callek) from comment #8)

> If you in-fact tested on SM 2.6a2 then its actually newer than 2.5 Beta 1,
> regardless of build date.

I am building my own SMs nearly daily and can easily test older builds in my archive in which the folders are automatically named after the build date. Currently i am using SM 2.7a1.

Releases? No interest. ;)
(In reply to Justin Wood (:Callek) from comment #8)
> If you in-fact tested on SM 2.6a2 then its actually newer than 2.5 Beta 1,
> regardless of build date.

It's definitively 2.6a2 autoupdated via  aurora update channel
(In reply to Hartmut Figge from comment #9)
> (In reply to Justin Wood (:Callek) from comment #8)
> 
> > If you in-fact tested on SM 2.6a2 then its actually newer than 2.5 Beta 1,
> > regardless of build date.
> 
> I am building my own SMs nearly daily and can easily test older builds in my
> archive in which the folders are automatically named after the build date.
> Currently i am using SM 2.7a1.
> 

In that case, would you be willing to "regression-hunt" this down for me/us.

What I want is:

First Broken Build: <>
Last Good Build: <>

Where good is "Cannot reproduce this bug". Getting the range down to as close to a 24 hour period as possible. And noting the cset as per about:buildconfig, and buildid per about:support.
(In reply to Justin Wood (:Callek) from comment #11)

> In that case, would you be willing to "regression-hunt" this down for me/us.

Hm, i have already given this information in comment #1.

> What I want is:
> 
> First Broken Build: <>

2011-09-27 21:15:00 PDT

> Last Good Build: <>

2011-09-26 20:26:00 PDT

> Where good is "Cannot reproduce this bug". Getting the range down to as
> close to a 24 hour period as possible.

Almost 24 hours.

> And noting the cset as perabout:buildconfig, and buildid per about:support.

Not neccessary. The build dates are automatically transferred to the names of the folders by my build script. ;)

Because these dates are in CET/CEST, they must be translated to PDT. This is done by another script with the name fenster.
Confirmed, regression.

WFM in 2.4.1

WFM in Mozilla/5.0 (Windows NT 5.1; rv:9.0a1) Gecko/20110920 Firefox/9.0a1 SeaMonkey/2.6a1

Broken in  Mozilla/5.0 (Windows NT 5.1; rv:9.0a2) Gecko/20111004 Firefox/9.0a2 SeaMonkey/2.6a2

Nothing in Error Console that I see.
I just realized from external applications (Firefox) the bug does not appear for me only from inside SeaMonkey 2.7a1.
Attached image buildconfig
In reply to comment #11
Attached image about:support
In reply to comment #11

Too little coffee. d&r
(In reply to Justin Wood (:Callek) from comment #8)
[...]
> I also tested on win7, fwiw. Not linux64. CC-ing someone who can probably
> assist more here (in terms of testing).

Mozilla/5.0 (X11; Linux x86_64; rv:10.0a1) Gecko/20111005 Firefox/10.0a1 SeaMonkey/2.7a1 ID:20111005003004

Reproducible: Always

I reproduce the bug on this Mozilla-built nightly: clicking on the link in the attachment opens an email-compose window with empty "To:" and "Subject:" fields. The "From:" drop-down is set at my default mail account and identity.
Status: UNCONFIRMED → NEW
Component: General → MailNews: Composition
Ever confirmed: true
Keywords: regression
QA Contact: general → mailnews-composition
Wayne: does this bug also happen on Thunderbird 9.0a2 or later?
(In reply to Hartmut Figge from comment #12)
> (In reply to Justin Wood (:Callek) from comment #11)
> 
> > In that case, would you be willing to "regression-hunt" this down for me/us.
> 
> Hm, i have already given this information in comment #1.
> 
> > What I want is:
> > 
> > First Broken Build: <>
> 
> 2011-09-27 21:15:00 PDT
> 
> > Last Good Build: <>
> 
> 2011-09-26 20:26:00 PDT
> 

Ok, that is helpful, but nothing in c-c sticks out at me: http://hg.mozilla.org/comm-central/pushloghtml?startdate=2011-09-25&enddate=2011-09-27

> > Where good is "Cannot reproduce this bug". Getting the range down to as
> > close to a 24 hour period as possible.
> 
> Almost 24 hours.
> 
> > And noting the cset as perabout:buildconfig, and buildid per about:support.
> 
> Not neccessary. The build dates are automatically transferred to the names
> of the folders by my build script. ;)

Yes it is necessary, I want the csets! That is what I can use to translate your build dates to a real regression range., otherwise there is quite a big gap in what this could be, especially when talking about mozilla-based changes.
The build ID (source datestamp to the second) is not found in about:support; it could be displayed by the Nightlmy Tester Tools extension but I don't know how precise it would be for an own-built executable.

The Mercurial comm-central and mozilla-central changesets from which the "last good" and the "first bad" executables were built are, as Callek said, the only way to know precisely where the limits are between sources "known to be good", "undecided" and "known to be bad". If you have kept the logs from the last "python client.py checkout" before building, they are displayed as "Updated to revision xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx." where the x's are hex digits, immediately after invoking hg update for mozilla-central and comm-central. There are similar lines lower down for ChatZilla, Dom Inspector, the LDAP SDK and Venkman but this particular bug doesn't sound like it might result from a bug in any of the latter four.

The mozilla-central changeset is normally also displayed near the top of about:buildconfig; I don't know why yours (which seems to be from a 32-bit build) doesn't show it. Here are the first few lines of about:buildconfig for the build whose user-agent and build ID are mentioned in comment #17; I obtained them by copy and paste:


about:buildconfig
Source

Built from http://hg.mozilla.org/mozilla-central/rev/70e4de45a0d0
Build platform
target
x86_64-unknown-linux-gnu
After widening the search window a little, I see several mailnews changesets, but I'm not competent to say which ones might or might not be relevant. David, can you help? Here is the URL I used:

http://hg.mozilla.org/comm-central/pushloghtml?startdate=2011-09-25&enddate=2011-09-28
I tested with some nightlies from the FTP Server
good: 
Build identifier: Mozilla/5.0 (X11; Linux x86_64; rv:9.0a1) Gecko/20110926 Firefox/9.0a1 SeaMonkey/2.6a1
Source
Built from http://hg.mozilla.org/mozilla-central/rev/c722928d8b69

bad:
Build identifier: Mozilla/5.0 (X11; Linux x86_64; rv:9.0a1) Gecko/20110927 Firefox/9.0a1 SeaMonkey/2.6a1
Source
Built from http://hg.mozilla.org/mozilla-central/rev/803b01dcc589

is that the info you need?
You might have to broaden the change sets to include mozilla-central. But isn't this a dup of bug 691288, which has a fix up for review?
(In reply to David :Bienvenu from comment #23)

> You might have to broaden the change sets to include mozilla-central. But
> isn't this a dup of bug 691288, which has a fix up for review?

Applying this fix solves the problem here.
thx.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: