[ANNOYANCE] Custom protocols that are not registered do not trigger browserBeforeNavigate correctly on windows.

[Terry Judd]

What's really annoying is that you used to be able to grab data from form
elements using browserBeforeNavigate - the values of the form elements would
be reported in the url variable, even if no action was ascribed to the form.
This was really useful as you could use a webform to capture some user
entered data, intercept it with browserBeforeNavigate, process and/or store
it in Rev and then do some other stuff - in some cases removing the need for
server-side logic or cookies (for example, I used it to store and retrieve
student's quiz answers submitted during a session).

This still works in OSX (you just have to parse some 'garbage' off the front
of the URL) but broke in one of the earlier versions of the revBrowser
externals for Windows. AFAIA, it still works with the original altBrowser
external.

I reported this some time ago (more than 3 years) but it was never fixed and
my original bug report has disappeared. I for one would like to see this
feature reinstated.

Anyone else?


On 8/08/10 9:50 AM, "Andre Garzia" <andre at andregarzia.com> wrote:

> Folks,
> 
> Sometimes do you want to create some fancy interface using RevBrowser and
> want to communicate back with the stack that hosts the RevBrowsr view. One
> quick way of doing this is to use custom protocols (so that you know that
> url is yours) such as:
> 
>   myapp:refreshGui
>   myapp:executeHandler/doStuff
> 
> For example, some construct like:
> 
>   <a href="myapp:refreshGui">Click here to Refresh GUI</a>
> 
> When that link is clicked, you could use a browserBeforeNavigate handler
> such as this one:
> 
>   on browserBeforeNavigate pID, pURL
>     set the itemdel to ":"
>     if word 1 of pURL is "myapp" then
>       -- our protocol!
>       switch word 2 of pURL
>         case "refreshGui"
>           refreshGui
>           break
>       end switch
>     put true into browserCancel
>     end if
>   end browserBeforeNavigate
> 
> 
> This of course works great on Mac OS X and you can create your own browser
> windows that trigger things back with no problem and you don't mix
> http://or other protocols with your own, very elegant.
> 
> Now on Windows land (damn you Redmond!!!) things are different. It appears
> that browserBeforeNavigate is only triggered afted IE renderer inspects the
> URL. When it finds out a custom protocol, it checks to know if the system
> can handle it. If you are using your own and haven't fiddled with Windows
> Registry to register it, that check will fail and IE will change the damn
> URL for you pointing to a internal windows dll page showing something like:
> "Hey Fella, I don't know how to handle this!" which of course is an exercise
> in patience since my own browserBeforeNavigate will prevent IE from even
> trying to handle my own protocol.
> 
> This is not a RevBrowser BUG per se since RevBrowser is not doing anything,
> it is IE again in its infinite wisdom trying to do things for you (which it
> shouldn't). The only solution in these case is to add lots of Registry
> information, registering your own protocol, which will probably make windows
> try to relaunch your standalone for every of those links.
> 
> Damn, microsoft always makes my life harder!
> 
> Andre
> 
> 
> 

--
Dr Terry Judd | Senior Lecturer in Medical Education
Medical Education Unit
Melbourne Medical School
The University of Melbourne