Based on the w3schools site: "There is no public standard that applies to the navigator object, but all major browsers support it.".
I somehow see the navigator object as rather important, and with the rate at which browsers change their versions today even more so. So it rather baffles me that there is no standard for it.
What baffles me even more is that none of the browsers seem to have come up with the idea to include the two most important properties into this object:
navigator.browserName
navigator.browserVersion
We all have to parse the darn navigator.userAgent and hope from version to version that stuff in there did not change too much. Like it just did in IE11 for example...
How can one even write a W3C proposal for a new standard?
Thanks to #Alohci and some more digging, since the Navigator object has a standard, the way to go about proposing a change to it is to send an email to the public-html#w3.org
Related
Is there any standard (possibly created after-the-fact) that governs <!DOCTYPE NETSCAPE-Bookmark-file-1> files? If you export bookmarks from either Chrome or Firefox (tried on Windows 10) you get this kind of file, which seems to be HTML of sorts.
I've tried searching the web but found only pragmatic results like parsers in specific programming stacks, or tips and tricks on importing and exporting it.
Is there any standard, RFC, format description, or reference parser, or something similar?
Not even valid HTML it is, neither technically, nor semantically. And it seems that modern browsers interpret the factual standard loosely when writing such files, but luckily also when importing.
The best available format description (probably reverse engineered, yes) seems to be this one:
https://learn.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/platform-apis/aa753582(v=vs.85)
And it's by Microsoft of all things...
I read the whole Puppeteer documentation, but unfortunately, they don't have any documentation for the _client property of page.
So my question is, what is page._client ?
And what is the difference between using
await page._client.send('');
And
client = await page.target().createCDPSession()
await client.send('');
By JS convention, fields and methods that are prefixed with an underscore like _client are "private", and are not to be relied upon. This is almost certainly also the reason why it is not documented. You are using it at your own risk. In a newer version of puppeteer this field may be gone or do something entirely different.
Newer flavors of JavaScript have proper private fields and methods (prefixed with # in the class definition), so most likely puppeteer will convert these fields to proper private fields soon.
There is no documentation for page._client.
Avoid page._client as it is a private API.
You can get a client object with await page.target ().
page._client is used internally by puppeteer classes. As people have pointed out above, it is best, if not always to avoid using page._client as it is a private API.
Create your own CDP Sessions page.target().createCDPSession() to access the chrome devtools protocol directly. Things might work when you use page._client, but when you start to try to implement some of the low level features of the devtools protocol by yourself, there are going to be some collisions and bugs that arises that aren't documented anywhere and you will be left scratching your head wondering if chrome devtools is so broken.
Example of this errors is like when you could try to use the Fetch domain directly to do proxy authentication instead of using page.authenticate(...). Things are going to break, and you are going to try to search the errors which are nowhere to be found, look at puppeteer source code and see you aren't doing anything different, but guess what, since you used page._client.send(...) instead of creating your own CDPSession, you're going to pay the price of spending a whole day debugging your code.
#see: https://github.com/puppeteer/puppeteer/blob/v10.4.0/docs/api.md#class-cdpsession
Gmap.addoverlay() causes map to zoom out if you've called getEarthInstance().
Using ge plugin 6.2.1.6014, Chrome/Mac OSX and {Firefox,Chrome}/Windows Vista Home Premium (Cross-posted on Google Earth API issues). See the test code here.
Shortly after the second marker appears, the maps zooms out, even though noone asked it to.
By putting an alert() in that callback and extending the timeout() interval, I'm pretty sure it's the addOverlay(), not the getEarthInstance(), where the problem occurs.
To immunize my code, I tried the commented code in the callback, but it's apparently too late by then.
So, is there any way to determine the version of the plug-in without calling getEarthInstance()? Perhaps some hacking with google.load? Without a clean way to detect the version of the plug-in, I'd have to disable the G_SATELLITE_3D_MAP as long as any of this version of the plug-in remain installed out there, which, I'm thinking, is pretty much forever?
I'm calling getEarthInstance() because I want to enable a few layers and set a click listener on the globe. Is it possible to do either of those things without getEarthInstance()?
I haven't used v2 of the Maps API extensively, so maybe this is a long-known behavior, but this does appear to be a bug. I suggest filing it on the Maps API v2 issue tracker, as the plugin itself (or the plugin API) can't really do anything to change the view of the map.
Please note that v2 of the API has been deprecated (since May 2010!), so they are only fixing regressions. Also, you should really consider switching to v3 of the API; there's even a handy library for Earth API integration.
In the meantime, there are a few approaches that might help:
Is there a reason that you're checking the version number of the
plugin? There have been some additions to the API in recent
releases, but I'm not sure what in 6.2 would be a deal-breaker. The
plugin has used the same auto-updater as Google Earth for some time
now, so the vast majority of users are on the latest version of the
plugin anyway. There are a handful of holdouts on 5.x and 6.0 for
specific reasons, but there really aren't very many. For almost
everyone that visits your site, the isSupported() check should be
sufficient, and if it isn't, they have probably purposefully opted
out and know why things aren't working.
Since you're loading the earth Javascript library anyway, you can
consider just loading an instance of the plugin without involving
the API. google.earth.createInstance will help you out there
(you can use a hidden html element if that matters, just make sure
to detach it and let it be garbage collected when you're finished).
There is some overhead in starting up a plugin instance and then
discarding it, but it's pretty minor over just starting it, which
you're already doing here. The next plugin instance will also be
created more quickly when the view is switched to 3D.
To anyone who's been hit by this bug, thanks to the suggestion in the answer by Mr. Kenny, here's some code to check the plug-in version without falling victim to the bug we're trying to avoid:
function enable_geplugin(map, div, callback) {
if (!google.earth.isSupported())
return;
var earth_div = document.createElement('div');
document.body.appendChild(earth_div);
earth_div.style.height = '1px';
earth_div.style.width = '1px';
google.earth.createInstance(
earth_div,
function(instance) {
if (!instance.getPluginVersion().match(/^6\.2\./)) {
map.addMapType(G_SATELLITE_3D_MAP);
if (callback)
map.getEarthInstance(callback);
}
earth_div.style.display = 'none';
document.body.removeChild(earth_div);
},
function(errorCode) {
// do this so user can click on map type "Earth" and see the download instructions
map.addMapType(G_SATELLITE_3D_MAP);
earth_div.style.display = 'none';
document.body.removeChild(earth_div);
}
);
}
Used, for example, here.
(On OSX/Chrome, the document.body.removeChild(earth_div) generates an Uncaught ReferenceError: NPObject deleted, but that's the least of my worries.)
So we can now effectively disable G_SATELLITE_3D_MAP for bad plug-in releases, but I still hope someone working on the plug-in fixes the bug itself.
Is there any sort of documentation on exactly what parameters you can put in the url of Google viewer?
Originally, I thought it was just url,embedded,chrome, but I've recently come accross other funny ones like a,pagenumber, and a few others for authentication etc.
Any clues?
One I know is "chrome"
If you've got https://docs.google.com/viewer?........;chrome=true
then you see a fairly heavy UI version of that doc, however with "chrome=false" you get a compact version.
But indeed, I'd like a complete list myself!
I know this question is very old and perhaps you already solved your issue, but for anyone on the internet who might be looking for an answer...
I have been looking for this recently, following a guide I found on GitHub Gist
https://gist.github.com/tzmartin/1cf85dc3d975f94cfddc04bc0dd399be
More specifically, the option to embed a certain page of pdf using
<iframe src="https://docs.google.com/viewer?srcid=[put your file id here]&pid=explorer&efh=false&a=v&chrome=false&embedded=true" width="580px" height="480px"></iframe>
The best I could fing was this article (I suppose from a long time now)
https://weekly-geekly.github.io/articles/111647/index.html
HOWEVER, I tried modifying the attributes and the result was simply a redirect to
https://drive.google.com/file/d/[ID]/edit
https://drive.google.com/file/d/[ID]/preview or
https://drive.google.com/file/d/[ID]/view
AS OF MAY 2020, THIS SOLUTION PROBABLY DOESN'T WORK
I'm also on a quest to discover some of the parameters of the viewer.
the "chrome" parameter doesn't seem to do anything, though. Is this
supposed to be the same as embedded=true?
Parameters I know of:
url= (obviously)
embedded= (obviously)
hl= set language of UI (tooltips)
#:0.page.1 = jump to page 2 (page 1 is numbered 0) - this is unreliable and often requires a refresh after the first load,
defeating the purpose.
That said, when I use the Google Docs viewer on my site, "fit page to
screen" is the default view without any parameters. So maybe I'm
misunderstanding your question.
Source: For convenience, this is a full quote of the sole answer (it is from user k3david) to the crosspost of this question #Doc has posted to the Google support forum in 2011.
You can pass q=whatever to pass a search query to the viewer.
I'm looking into ways to develop an extension for IE6+ that will allow handling of custom MIME types.
As an example, I need to be able to take a document with a custom MIME type that is returned by the server, perform some processing on it, and then change the MIME type back to something that IE can natively handle, such as text/html or image/jpeg.
I am familiar with the urlmon MIME filters, but they have a huge weakness; they are only invoked for the top level document, and not for any of the additional page content such as images and the like.
The one way that I can think of that will work is to hook the HTTP/S protocol handlers using vtable/iat patches, similar to the way Google Gears works, to be able to intercept the response headers, and modify the headers and response body when a document with the specified MIME type is received.
I'm wondering if anybody else has any good ideas on how this could be accomplished in a less hacky/intrusive way.
Edit:
Just thought I'd follow up on this and mention that I went with the vtable patch into the HTTP/S protocol handlers, and it worked much better than I expected. If anybody else is looking to do something like this, I highly recommend taking a look at the HttpHandlerPatch class in Google Gears for some inspiration.
Several years ago, I wrote such extensions, BHO, IE toolbars, etc., based on a book called Shell Programming in VB6. The book I used is this one: http://oreilly.com/catalog/9781565926707/ This book tells you how to hook and trap messages coming into IE. I wrote a kind of screen scraper (post-render style not like a spider that doesn't execute the javascript first). It was based on IE5 but the extensions still work with IE6. I probably still have the VB6 source somewhere. I am not offering to upgrade it to .Net for you though.
PS. The review on that page by Haroeris Astrum is by me :)