308196 - remote xfeDoCommand(composeMessage,to=name@domain,subject=FileName,attachment=file:///path/to/file,body=text) broken in thunderbird

Status: RESOLVED FIXED

(Thunderbird :: General, defect)

Description

[Roberto Salomon]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4
Build Identifier: 

I am using a script to automate the sending of files. The script call to
Thunderbird is:

/opt/thunderbird/mozilla-xremote-client -a thunderbird
"xfeDoCommand(composeMessage,to=name@domain,subject=FileName,attachment=file:///path/to/file,body=Short
text")

Untill 1.5 Beta1, the above call resulted in a new message compose window with
the to field, subject, body and attachment correctly filled out. Now, the
compose window opens with all fields and information blank.

Reproducible: Always

Steps to Reproduce:
Run the command line above
Actual Results:  
A new compose window with all fields blank

Expected Results:  
A message ready to be sent.

Comment 1

[Magnus Melin [:mkmelin]]

Confirming with
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b5) Gecko/20050924 Thunderbird/1.4
ID:2005092407

Do you know which the last working build was? 


BTW, in the steps to reproduce, that would be 'text)"' not 'text")'.

Comment 2

[Magnus Melin [:mkmelin]]

Working: 2005-04-03 
Broken:  2005-04-14

The xremote checkins I found for that period was for bug 289383 and bug 280725,
both by bsmedberg%covad.net. 

Any take on this Benjamin?

Comment 3

[Benjamin Smedberg]

See the patch in bug 281847, which will probably fix this.

Comment 4

[Magnus Melin [:mkmelin]]

(In reply to comment #3)
> See the patch in bug 281847, which will probably fix this.

Seems not:( Bug 281847 is now fixed, this still isn't working.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b5) Gecko/20051005
Thunderbird/1.4.1 ID:2005100506

Comment 5

[Scott MacGregor]

I don't have a linux machine so I can't easily investigate this. 

Do you have a debug build handy where you can add some dump statements inside of: 

http://lxr.mozilla.org/seamonkey/source/mail/components/nsMailDefaultHandler.js#162

to see if that code is getting executed?

Comment 6

[Magnus Melin [:mkmelin]]

Yep, the code is executed. But at (I assumed the you meant the thunderbird
version of this) 
http://lxr.mozilla.org/mozilla1.8/source/mail/components/nsMailDefaultHandler.js#152

the argstring is '', therefore no fields filled in I guess. 

Something like

XXXmkmelin xfedocommand
XXXmkmelin composemessage
XXXmkmelin wwatch=[xpconnect wrapped nsIWindowWatcher @ 0x868cc90 (native @
0x81bf340)]
XXXmkmelin argstring=

Comment 7

[Scott MacGregor]

Benjamin, it looks like the old xremote code took the passed in argument text
and pre-pended "mailto:" to it then passed the result to openurl:

http://lxr.mozilla.org/aviary101branch/source/xpfe/components/xremote/src/XRemoteService.cpp#273

Maybe we should do something similar here when processing xfeDoCommand: 

http://lxr.mozilla.org/mozilla1.8/source/mail/components/nsMailDefaultHandler.js#126

Comment 8

[Scott MacGregor]

thoughts on comment 7 benjamin?

Comment 9

[Benjamin Smedberg]

Scott, we handle the "mailto" case correctly at
http://lxr.mozilla.org/mozilla1.8/source/mail/components/nsMailDefaultHandler.js#121

It's the "xfeDoCommand" case formerly handled at
http://lxr.mozilla.org/aviary101branch/source/xpfe/components/xremote/src/XRemoteService.cpp#1044
which for some reason doesn't match up with
http://lxr.mozilla.org/mozilla1.8/source/mail/components/nsMailDefaultHandler.js#149

Comment 10

[Scott MacGregor]

right, that's what I said in comment 7. I think we are saying the same thing, we
are ignoring the argument passed into xfedocommand we should be pre-pending
mailto to the argument text and passing that into the compose window like we
used to do. That's what I was trying to say anyway.

Comment 11

[Benjamin Smedberg]

But XRemoteService.cpp#1044 doesn't do that...

Comment 12

[Scott MacGregor]

in the 1.0 branch we did passed in the argument to the compose window which is
what I was looking at:

http://lxr.mozilla.org/aviary101branch/source/xpfe/components/xremote/src/XRemoteService.cpp#986

I still feel like we are saying the same thing. The new code isn't doing what
the old code did for xpfeDoCommand. :)

Comment 13

[Benjamin Smedberg]

Attachment: Actually set the argstring, rev. 1

Scott, this is basically untested, I probably won't have a build with this
until tomorrow sometime but it should work.

Comment 14

[Scott MacGregor]

cool. Magnus, can you find some time today to test this patch in your local
build for us? 

Comment 15

[Magnus Melin [:mkmelin]]

(In reply to comment #14)
> cool. Magnus, can you find some time today to test this patch in your local
> build for us? 

Sure, I'll try it out in the evening.

Comment 16

[Benjamin Smedberg]

Whoops, I thought r+ was marked. I tested and checked this in on trunk with one
change: instead of argstring.setData() which doesn't exist, I used the proper
argstring.data.

Comment 17

[Magnus Melin [:mkmelin]]

Tried the patch. With argstring.data= instead of argstring.setData() it works fine.

Comment 18

[Scott MacGregor]

Comment on attachment 199848 [details] [diff] [review]
Actually set the argstring, rev. 1

awesome. Benjamin can you check this into the branch then too with the same
change?

Comment 19

[Benjamin Smedberg]

Fixed on branch as well.

Comment 20

[Roberto Salomon]

When will the patch make it to a trunk build so it can be tested?

Comment 21

[Magnus Melin [:mkmelin]]

(In reply to comment #20)
> When will the patch make it to a trunk build so it can be tested?

Should be in the 2005-10-19 branch/trunk builds.

Comment 22

[Roberto Salomon]

Tested on 1.6a1 (build 20051116). Confirmed that xfeDoCommand now composes the message correctly on this build.

Thanks for the great work.