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
Related
I was trying to repro a tutorial about the creation of an Excel Add-in when something get wrong with the IntelliSense of Visual Studio. I was writing this code:
function updateStocks() {
Excel.run(function (ctx) {
var **range** = ctx.workbook.names.getItem("Stocks")
At this step, everything was fine, but after the getItem, I have tried to add .getRange() at which point the IntelliSense was not able to understand anything related to my variable range.
Screenshot
What is really "funny" is the fact that even if the properties are not displayed, when I write the code of the tutorial manually, the code is executed without mistake.
Why does this behavior occur and how can I correct it?
Are you able to see IntelliSense for other types within that .run? I.e., do you have everything up to the point where you get a Range from a named item? If you were to obtain the range differently (e.g., context.workbook.getSelectedRange()), do you get IntelliSense then?
This might be related to an issue (now fixed) where the CDN accidentally had the namedItem.getRange method removed (it was the only one that was affected, and we've put in measures to ensure we catch those in the future). See "Can't get range from a defined name". The CDN has been patched a couple weeks ago, but the JS IntelliSense file ("VSDOC") probably hadn't. If that's the case, it's a point-in-time issue that should resolve itself very very soon, as new deployments of the CDN will have the getRange method both in the VSDOC and everywhere else.
FWIW, you may still run into limitations of the JS IntelliSense engine (there are plenty, unfortunately: for example, trying to pass values across Promises, or passing in API objects as parameters to functions). The only true good workaround for this is using TypeScript, which allows you to declaratively assert to the compiler/IntelliSense-engine that "I know this type is an Excel.Range!") -- and offers a number of other goodies, async/await being a very major one. I personally believe that if you really want a "premier" Office.js-coding experience, TypeScript is the way to go. To that end, I describe how to use TypeScript in my book, "Building Office Add-ins using Office.js" (full disclosure, I am the author; but I've had many readers comment on how helpful of a resource it's been to them). The book is very much TypeScript-oriented, IntelliSense being one of the reasons (and async/await and let being the primary others) -- though I also offer an Appendix where I describe the JavaScript-only way of accomplishing the same Office.js tasks. It takes only a small amount of effort to get started with using TypeScript, and once you do, I don't think you'll look back.
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
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 want to add a calendar control to a page that already includes Prototype and Scriptaculous. Not happy with any of the Prototype ones I could find, I'm considring using the YUI Calendar widget.
I this likely to cause any problems?
We have worked hard to make sure that YUI is safe to use with any other library. We namespace everything, as HermanD says, under only one required global (YAHOO) and one optional one (YAHOO_config). We don't modify native objects. And even though Protoype does modify native prototypes, we code defensively so that this doesn't break YUI functionality.
If you find any bugs in using the two together, please let us know.
Regards,
Eric
YUI Team
By default everything in YUI is within the YAHOO namespace, so as long as you sensibly apply namespaces to anything you use from YUI, I would have thought you should be ok.
See: http://developer.yahoo.com/yui/yahoo/
I successfully used the YUI tab control in an app I was already using Prototype and Scriptaculous in and had no problem. The weight of all that is a bit much though if you're looking at a publicly available app. I wouldn't care so much about an internal app, say for a company, but you might want to think about how much JavaScript you're making end users download and the number of separate files they're having to download for the page.