536527 - starting prism with url parameter is missing

Status: RESOLVED FIXED

(Mozilla Labs :: Prism, enhancement)

Description

[Andreas Humenberger]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.1.6) Gecko/20091201 Firefox/3.5.6 (.NET CLR 3.5.30729) XPCOMViewer/0.9a
Build Identifier: 

It should be possible to start prism with an url parameter, e.g.:

prism.exe -override <override.ini> -webapp <webapp> -url <url>

This command should start a new prism thread with the given webapp if none presently exist.
And in case we have an existing prism process with the given webapp, there should popup a window in the context of the existing thread.

Reproducible: Always

Comment 1

[Andreas Humenberger]

Attachment: added url parameter for starting prism

Comment 2

[Andreas Humenberger]

Attachment: nsCommandLineHandler

changes:
 - prism can be started with an url parameter
    prism.exe -override <...> -webapp <...> -url <...>
 - prism checks if the current url is already opened wether prism will be started with the url parameter or not
   - if the url is opened, the window will be activated otherwise a new window will be opened

Comment 3

[Ryan]

If a Prism webapp is not already running, then the url parameter works as expected. However, if the webapp is already running, then trying to open another window for it does nothing.

For example, if my Gmail webapp is running, and I try to start another window in the Gmail webapp to handle a mailto: link, nothing happens.

Comment 4

[Andreas Humenberger]

In my case, this example works. Did you use "gmail.com" or "mail.google.com for the webapp?
If you used "gmail.com" it can't work because prism matches the hostnames, and gmail redirects you afer login to "mail.google.com".

So, if you try "mail.google.com" it should work as expected.

Comment 5

[Bernhard]

Right now we cannot use prism for our customers to access our system,
as any http-link sent by e-mail will still be opened in the default browser.
	
Our solution for windows is to add a ShellExecute-Hook to interfere 
with the standard mechanism and open the prism webapp instead.
However right now we do not have any means to pass the url to prism.

So if there is no “official” fix in the prism project for our problem,
we will have to build the stuff ourselves: not so nice.

Please let us know, how we can help to make this improvement happen.

Comment 6

[Matthew Gertner]

So you just need the -url parameter to work? This shouldn't be too difficult to fix if that's the case. I'll try to take a look next week.

Comment 7

[Ryan]

In my previous comment, I stated that the -url parameter works for a Prism webapp if that webapp is not already running. However, this no longer seems to work.

Ideally, I would like the -url parameter to open a new window with the url if the webapp is already running. That would allow me to use my Prism Gmail webapp to handle mailto: links by opening a new compose window just like a desktop email client. Right now I'm using a Chrome webapp for that.

Comment 8

[Bernhard]

Right, the "-url" parameter working would be great.

Comment 9

[Martin]

The "-url" parameter is a very good idea, to start the prism webapp on a link from e-mails.

Comment 10

[Mark Finkle (:mfinkle) (use needinfo?)]

Comment on attachment 421401 [details] [diff] [review]
added url parameter for starting prism

switching to Matt

Comment 11

[Mark Finkle (:mfinkle) (use needinfo?)]

Comment on attachment 421402 [details] [diff] [review]
nsCommandLineHandler

switching to Matt

Comment 12

[Matthew Gertner]

Comment on attachment 421402 [details] [diff] [review]
nsCommandLineHandler

Please submit a patch (not the complete modified files) so I can review this. You can create a patch by entering "svn diff" in the root directory of your Prism source tree. (If you didn't get Prism from SVN, you have to do so first.) Please let me know if you need further help creating the patch.

Comment 13

[Andreas Humenberger]

Attachment: patchfile for startin prism with an url

patchfile added

Comment 14

[Ryan]

I applied the patch, and it works nicely. I now handle mailto: links with my main Gmail webapp, and it works as expected. Very cool.

Comment 15

[Matthew Gertner]

Comment on attachment 450321 [details] [diff] [review]
patchfile for startin prism with an url

Andreas, this looks very good. The one issue is that I don't think you need to make any changes to nsPrismStub.cpp. The reason that -override and -webapp are handled in the stub is that they are needed before nsCommandLineHandler.js is run. I don't this is the case with -url, so you can remove the code from the stub and just use handleFlagWithParam (i.e. no environment variable).

Please make this change and resubmit for review. I'll then try to get it checked in ASAP and release a new Prism beta (1.0b5) with this improvement included.

Comment 16

[Andreas Humenberger]

In my tests without the changes in nsPrismStub.cpp the -url parameter didn't work if Prism is not already running.

Comment 17

[Matthew Gertner]

(In reply to comment #16)
> In my tests without the changes in nsPrismStub.cpp the -url parameter didn't
> work if Prism is not already running.

That's odd. What platform are you testing on?

Comment 18

[Andreas Humenberger]

Attachment: patchfile for startin prism with an url

I made a mistake when testing. You're right, the changes in the stub are not necessary.
I added the patchfile for nsCommandLineHandler.js.

Comment 19

[Matthew Gertner]

Comment on attachment 451904 [details] [diff] [review]
patchfile for startin prism with an url

Still doesn't seem quite right to me. activeWindow should always be called since on Mac, the main window might be hidden and we need to make sure it is made visible again. I would suggest storing the win to use (if any) in your loop and calling activateWindow outside of the loop (so the win parameter sometimes has a value and is sometimes null).

Comment 20

[Andreas Humenberger]

Attachment: patchfile for startin prism with an url

activateWindow will be called with the opened window or with the most recent one.

Comment 21

[Matthew Gertner]

Comment on attachment 452666 [details] [diff] [review]
patchfile for startin prism with an url

Looks good. I'll get this into the next build.

Comment 22

[Matthew Gertner]

Attachment: Handle malformed URIs

I ran some more tests with this and noticed that it doesn't handle cases where the URI is malformed. Prism is quite liberal in this regard and tries to interpret URIs that don't have a scheme (e.g. "www.google.com") or even a TLD (e.g. "google"). I changed your patch to use the URI fixup component instead of the normal IO service in order to handle these cases.

Comment 23

[Matthew Gertner]

Sending        components/src/nsCommandLineHandler.js
Transmitting file data .
Committed revision 69375.

Comment 24

[Matthew Gertner]

Attachment: Fix issues with protocol handlers

Further testing revealed that this change breaks protocol handlers registered by a Prism app. The main reason is that aCmdLine.handleFlagWithParam("url", ...) is called twice (erroneously), so the second time it always returns an empty string (the flag is removed when it is retrieved the first time). Also I don't think it is a good idea to set url to WebAppProperties.uri if it isn't specified on the command-line since subsequent code can't react properly (e.g. calling loadURI only if the URL was actually specified on the command line).

I should also note that this feature is not going to work on Mac as implemented, at least not to my knowledge. When I run it on Mac, it tells me that a copy of my app is already open, and it does this without triggering my command-line handler. I remember running into this issue in the past, and it was necessary to use a hidden window to catch the second invocation of the app. I'd need to investigate further to confirm that this is the right way to implement the feature on Mac. I know there have been some changes/improvements made to command-line handling on Mac.

Comment 25

[Matthew Gertner]

Attachment: Oops attached wrong patch

Comment 26

[Mark Finkle (:mfinkle) (use needinfo?)]

Comment on attachment 467782 [details] [diff] [review]
Oops attached wrong patch

Use Cc and Ci in the WindowMediator call. The code paths look tricky. Make sure to test this out across platforms a bit.

Comment 27

[Matthew Gertner]

Good call, I replaced some other places that should use Cc and Ci as well. Seems to work fine on Windows and Mac (protocol handler) though the URL thing only works on Windows, as I mentioned.

Sending        components/src/nsCommandLineHandler.js
Transmitting file data .
Committed revision 73444.