Daz wrote:
I believe that getBrowser is a
JavaScript function that is native to Mozilla/Firefox, but I am not
100% on that.
OK, this hint broke the circle, though the question was *really*
cryptic.
It would be much more helpful to read something like: "at URL ... I
have found a mention of getBrowser used for ... What is it and where is
it?".
////////////
There is not native getBrowser object in JavaScript client-side
scripting. Thus any researches of it are even more futile than the
search of the Holly Grail :-)
Nevertheless:
Firefox 2.0 makes the first big step in implementing client-side
session data storage which IE users are enjoying with since 5.0
<http://msdn.microsoft.com/workshop/author/behaviors/reference/behaviors/userdata.asp>
In the particular Firefox 2.0 implements XPCOM session store API over
nsISessionStore interface. One of methods available over this interface
is getBrowserState() method
<http://developer.mozilla.org/en/docs/nsISessionStore#getBrowserState.28.29>
At <http://developer.mozilla.org/en/docs/Session_restore_APIit is
referred by mistake as getBrowser() method (the author must be got
confused with GetBrowser from BrowserHawk).
Overall the code snippets from
<http://developer.mozilla.org/en/docs/Session_restore_APIare getting
my prize by the amount of errors per line of code. That is atop of the
fact that the quality of samples for XPCOM / netscape.security matters
is awful both for MDC and XULPlanet. It is so thoroughly insistently
perpetually awful that I can explain it only by:
1) all writing goes under intoxication.
2) no one (including Gecko developers themselves) has a clue on the
matters.
3) until the relevant technologies are tested and interfaces are frozen
- until then an "allowance encryption" is used. Thus if someone knows
the matter she will be able to correct the code in the needed way so
use it for testing. Anyone else will fail to use the code so she will
give up for now.
Needless to say that I believe and hope that the most favorable to
Mozilla option (the third one) is the real true.
I myself once had to work extensively with Netscape Capabilities APIs
for JVM and the involved matters. This way now I'm in the position of
Cicero listening some drunk Roman legionnaire from a far province :-) -
with some efforts made I can understand what a hey is he talking about
and write down his speech with the proper words and in the proper
grammatical forms.
Sorry for blah-blah, anyway...
So there is nsISessionStore interface, and this interface implements
getBrowserState method. There is no "getBrowser" method in it: that is
a phantasm of a MDC participant.
nsISessionStore interface is accessible over XPCOM interface for
Firefox 2.0 or higher. XPCOM interface is not accessible until the
needed privilege is granted to the browser. This way the restored code
is:
!!! Important: Google News corrupts strings on display if they contain
@ (at-sign). Because XPCOM call contains at-sign, this code will be
corrupted and not working if copied from your browser window. After
copy and past first locate the string
Components.classes['
and remove dotes (ellipsis) right after the single quote.
<html>
<head>
<title>getBrowserState</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
</head>
<body onload="
/* Firefox 2.0 or higher.
* Security restrictions are applied
* (cannot be run within the default sandbox).
*/
netscape.security.PrivilegeManager.
enablePrivilege('UniversalXPConnect');
var s = Components.classes['@mozilla.org/browser/sessionstore;1'].
getService(Components.interfaces.nsISessionStore);
s.init(self);
window.alert(s.getBrowserState());
">
</body>
</html>
P.S. No, I will not jump on correcting relevant sections on XULPlanet
or MDC - though anyone is welcome to replace the current nonsense at
<http://developer.mozilla.org/en/docs/Session_restore_APIwith the
posted sample.
First of all, IMHO it's like emptying an ocean with a bucket. Secondly
and most importantly I do not agree with the MDC concept of "OK, guys,
we've programmed some cool stuff, you tell us what is it doing". Excuse
me: it is not an end-users' task to document "black boxes" over
try-fail-success cycles. Each programmer has to place an fn initial
document clearly stating what the hay is done, how in the name is it
done, what the fricking arguments are required, what the hell methods
are supported. That can be a plain text file or a scan image copy of a
sticker from his desktop: *anything* to start with. Then we can test
it, report bugs, "put the flash" of nicer wording and samples.
That seems not only my opinion, but a background feeling of many other
people: at least from one year to another MDC fails to be as helpful as
expected for advanced Gecko features.
