Closed Bug 378942 Opened 13 years ago Closed 13 years ago
Restore ability to pass in a url at the command line and have it load in the start page
Bob, please correct me if I got any of this stuff wrong... Bob has testing scripts which used to work in 1.5.0.x for verifying the build ID and other information. It worked by downloading a version of Thunderbird and passing a url into the command line. This url was loaded in to the start page / message pane box by Thunderbird at startup. I assume the page has some interesting JS. This broke in Thunderbird 2 because of the command line interface re-write on the branch and trunk. As a result we aren't able to take advantage of Bob's testing script when we put out new releases of Thunderbird 2. We should try to fix this. I'm thinking about implementing a command line handler where Bob can pass something like: <thunderbird.exe> -startpageurl <some url> note the "-startpage" part. Bob, would that fix it satisfactorily from your point of view?
I think that would restore the functionality I had in Thunderbird 1.5, but Thunderbird was already the ugly step-child in relation to Firefox. If we are going to do this, perhaps we can work together and I can improve Spider so that the normal command line arguments I use with Firefox will work with Thunderbird. See <http://bclary.com/projects/spider/spider/chrome/content/spider/spider-help.html#starting>. Note that these arguments don't work in Thunderbird 1.5. I have to start Thunderbird via thunderbird -P profile url where url is the the "escaped" form of the spider url. See <http://test.bclary.com/bin/spider.pl> for the way I have to invoke Thunderbird 1.5 rather than using the command line handlers that work with Firefox. So, lets make this less about the passing of the url and more about making it possible to install a testing extension into Thunderbird that allows the ability to automatically test as much of the functionality as possible.
If I understand correctly, spider gets installed as a test extension into Thunderbird. You then want to invoke a piece of extension chrome via the command line by passing in: -chrome <chrome url to a chrome file defined by the spider extension> Here's an idea, I'd like to toss out...What if the spider extension handled it's own command line switch, i.e. <thunderbird.exe/firefox.exe> -spider --> Launch the default chrome for the spider extension and then if you still want the ability to pass in a specific chrome url in spider you could do: <thunderbird.exe/firefox.exe> -spider chrome://spider/content/spider.xul I think this is the preferred way for extensions to process command line arguments. There's even a document on devmo with the JS an extension needs to do this: http://developer.mozilla.org/en/docs/Chrome:_Command_Line That would work today for both Firefox and Thunderbird.
(In reply to comment #2) > > http://developer.mozilla.org/en/docs/Chrome:_Command_Line > > That would work today for both Firefox and Thunderbird. > <http://bclary.com/projects/spider/spider/components/spider-cmdline.js> Doesn't work in Thunderbird for some reason, but yes it would be the preferred method. I would appreciate any help in getting that to work in Thunderbird.
Ah cool! So after installing spider.xpi, I ran thunderbird.exe -spider on Thunderbird 2 for Windows and it brought up the main spider chrome UI. What should I do to see the problem? (Thanks for your patience!)
Install Spider into Firefox and try firefox -spider -url http://www.mozilla.org/ -depth 1 -domain www.mozilla.org -start -quit This shows why Firefox does by loading the content into the iframe. Then try the following in Thunderbird 1.5 thunderbird "chrome://spider/content/spider.xul?url%3Dhttp%253A%252F%252Fwww.mozilla.org%252F%26domain%3Dwww.mozilla.org%26depth%3D1%26timeout%3D0%26waittime%3D0%26autostart%3Don%26autoquit%3Don%26restrict%3Don" This does something similar to the Firefox behavior by loading the web page into the preview pane. Now try each approach in Thunderbird 2. I'm not sure what the "correct" behavior should be in Thunderbird.
This is so close to working for me in Thunderbird 2. Everything works great except for the -url http://www.mozilla.org parameter. For some reason the default command line handler is eating up this argument: -url http://www.mozilla.org so the spider command line handler never sees it. I'm not sure why since I would have expected the spider command line handler to get a first crack at the commands before the default handler is invoked. But maybe I just don't understand enough about the command line handlers: http://mxr.mozilla.org/mozilla/source/mail/components/nsMailDefaultHandler.js All of the rest of the arguments look like they get picked up and inserted into spider.xul. If I manually add the url and then click run, the urls load in the iframe of the spider chrome. I think we just need to figure out why the url field isn't getting through.
Actually the problem is in the compose command line handler. It has some code that looks for -url and always consumes the url even if the url doesn't end up looking like a mailto url: http://lxr.mozilla.org/mozilla/source/mailnews/compose/src/nsMsgComposeService.cpp#1504
This fixes the problem, there might be a better way to express it in the code though. Fix the compose cmd line handler so it only consumes the argument associated with the -url flag IFF the argument looks like a mailto url. This allows other command line handlers that also look for the -url flag to get a chance to see the url. We could also wrap the code that looks for a -url flag in a mac platform ifdef, but I'm too chicken to do that. It's possible by now that other apps in the wild pass -url into thunderbird and expect a compose window to come up on all platforms.
I do have some users of Spider that may depend on -url for Firefox, but I could easily add an additional flag that would not conflict with the url eating bird. That seems easier|better|less troublesome.
Comment on attachment 262973 [details] [diff] [review] fix the compose cmd line handler Even if Bob works around this in spider, I think we should still fix the behavior of the compose cmd line handler so it doesn't eat the url value for -url if the url isn't a mailto url.
Attachment #262973 - Flags: superreview?(bienvenu)
Comment on attachment 262973 [details] [diff] [review] fix the compose cmd line handler + // we don't want to consume the argument for -url unless we're sure it's a mailto url You might want to add a line to the comment to the effect that we'll figure out if it looks like a mailto: url a bit later in the code.
Attachment #262973 - Flags: superreview?(bienvenu) → superreview+
fixed on the trunk with the improved comment.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Comment on attachment 262973 [details] [diff] [review] fix the compose cmd line handler This change does not effect Firefox. This fixes a regression from 1.5.0.x that broke Bob Clary's automated spider extension as the command line changes in 1.8.1. cause thunderbird to consume the argument passed in with a -url flag even if the url isn't a mailto url. There could be other extensions out there besides just Bob's that can no longer handle a -url argument because of this regression.
Attachment #262973 - Flags: approval184.108.40.206?
verified fixed with Spider 0.0.2.4 and an opt trunk Thunderbird build. I was able to Spider a site via thunderbird -spider -url <url> -depth 1 -start -quit showing only the Spider window.
Status: RESOLVED → VERIFIED
Comment on attachment 262973 [details] [diff] [review] fix the compose cmd line handler approved for 220.127.116.11, a=dveditz for release-drivers if you land today
Attachment #262973 - Flags: approval18.104.22.168? → approval22.214.171.124+
Bob, can you verify again against tomorrow's nightly branch build?
(In reply to comment #16) > Bob, can you verify again against tomorrow's nightly branch build? > can do.
When Thunderbird automagically updated with my permission to version 126.96.36.199 (20070728, the ability to invoke the browser with a url ref click disappeared. The browser was, curiously enough, FireFox 188.8.131.52. It worked immediately before Thunderbird self-updated/reloaded, and failed immediately afterwards.
Rick: that has noting to do with this bug. (You can probably fix it by resetting firefox as default browser - first set some other browser as default and then firefox again.)
You need to log in before you can comment on or make changes to this bug.