Closed Bug 308196 Opened 19 years ago Closed 19 years ago

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

Categories

(Thunderbird :: General, defect)

x86
Linux
defect
Not set
major

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: salomon, Assigned: benjamin)

Details

(Keywords: fixed1.8, regression)

Attachments

(1 file)

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.
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")'.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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?
Keywords: regression
See the patch in bug 281847, which will probably fix this.
(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
Summary: mozilla-xremote-client broken on 1.5 beta1 → remote xfeDoCommand(composeMessage,to=name@domain,subject=FileName,attachment=file:///path/to/file,body=text) broken in thunderbird
Flags: blocking1.8rc1?
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?
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=
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
thoughts on comment 7 benjamin?
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.
But XRemoteService.cpp#1044 doesn't do that...
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. :)
Scott, this is basically untested, I probably won't have a build with this
until tomorrow sometime but it should work.
Assignee: mscott → benjamin
Status: NEW → ASSIGNED
Attachment #199848 - Flags: review?(mscott)
cool. Magnus, can you find some time today to test this patch in your local
build for us? 
(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.
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.
Tried the patch. With argstring.data= instead of argstring.setData() it works fine.
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?
Attachment #199848 - Flags: review?(mscott)
Attachment #199848 - Flags: review+
Attachment #199848 - Flags: approval1.8rc1+
Fixed on branch as well.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Keywords: fixed1.8
Resolution: --- → FIXED
When will the patch make it to a trunk build so it can be tested?
(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.
Flags: blocking1.8rc1?
Tested on 1.6a1 (build 20051116). Confirmed that xfeDoCommand now composes the message correctly on this build.

Thanks for the great work.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: