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

[Ben Rubinstein]

On 09/08/2010 13:55, Andre Garzia wrote:
> I believe that this can be "fixed" by using client side javascript only. By
> fixed I mean "restore that behaviour". If you specify an action that is a
> javascript function and in that function you assemble your parameters in a
> url and set the window.location of the running page, it should trigger
> browserBeforeNavigate with the URL from the js function and your parameters
> there. This should work on both windows and mac os x and it is quite an
> elegant solution.

Bear in mind that while this works if you genuinely want the browser to 
display a new URL (you just want to do stuff first), it is limited as a means 
of calling back to Rev in general (but it is AFAIK the only way to do so).

In effect (from memory, syntax may be dodgy) you can have a javascript 
function like this:

	function tellRev (tMessage)
	{
	   window.location = "SPECIALREV:" + tMessage;
	}

	tellRev("beep");
	tellRev("show-onscreen-keyboard");
	....etc

A browserBeforeNavigate handler can then catch the URL, spot the special 
'protocol' prefix, do something with the rest of the so-called URL, and tell 
the browser to cancel the navigation.

This works up to a point: the issue, at least on Mac OS X, is that when 
javascript executes two statements to set window.location in succession, as in 
the above example, one cancels the other.  So if for example you have two 
controls on the web page, each of which instructs Rev to do something, if the 
user clicks both in quick succession, only one will execute.

See
http://quality.runrev.com/qacenter/show_bug.cgi?id=6986

for a proposed solution (which I admit I don't know if it's possible).

Ben