I recently ran our website through our PhantomJS testing suite and ran into JavaScript errors that I can't reproduce in my browser manually. These errors are found in the Google maps api and the text returned by Capybara is as follows:
TypeError: Unable to delete property.
TypeError: Unable to delete property.
at :215
at https://maps.gstatic.com/maps-api-v3/api/js/19/3/main.js:20 in cf
at https://maps.gstatic.com/maps-api-v3/api/js/19/3/main.js:20 in cf
at https://maps.gstatic.com/maps-api-v3/api/js/19/3/main.js:19
at :214
at https://maps.gstatic.com/maps-api-v3/api/js/19/3/main.js:20 in cf
at https://maps.gstatic.com/maps-api-v3/api/js/19/3/main.js:20 in cf
at https://maps.gstatic.com/maps-api-v3/api/js/19/3/main.js:21
at :176
at :31
at https://maps.gstatic.com/maps-api-v3/api/js/19/3/main.js:26 in Yf
at :178
Is this a known bug with Capybara, PhantomJS, or the Google maps API? Could the problem be caused by the user agent string in PhantomJS?
I'm using Cucumber / Poltergeist and I hacked around this in by creating the following extension:
/features/support/env.rb
Capybara::Poltergeist::Driver.new(app,
:extensions => ["features/support/ignore_gmaps_errors.js"]
)
/features/support/ignore_gmaps_errors.js
window.onerror = function(message) {
if (message == 'TypeError: Unable to delete property.') {
console.log('Ignoring gmaps error');
return false;
} else {
return true;
}
};
Google maps API experimental version was updated this morning (12/11) causing this breakage. By default when you include:
<script src="//maps.googleapis.com/maps/api/js?libraries=places"></script>
it uses the latest experimental version. Locking yourself to the latest release version:
<script src="//maps.googleapis.com/maps/api/js?v=3&libraries=places"></script>
should fix this.
Using the latest experimental version of Google Maps (v3.19), which includes a workaround, fixed this problem for me: https://code.google.com/p/gmaps-api-issues/issues/detail?id=7475#c20
[Edit] Google Maps v3.19 was released as the production version on 17 Feb 2015. Also, PhantomJS version 2 was released on 23 Jan 2015 incorporating an updated WebKit module which doesn't exhibit the Unable to delete property problem.
Try setting the user agent to
Mozilla/5.0 (Windows NT 6.0) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.41 Safari/535.1
Google delivers JavaScript that is not entirely runnable with its default user agent. PhantomJS 1.x is based on a really old fork of QtWebKit which is comparable to Chrome 13 (the reason for that user agent string).
It looks like you can do this this way:
#session = Capybara::Session.new(:poltergeist)
#session.driver.headers = { 'User-Agent' => 'Mozilla/5.0 (Windows NT 6.0) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.41 Safari/535.1' }
Related
Whichever WebGPU example (austin-eng, jack1232/WebGPU-Step-By-Step, etc...) I run in Chrome Canary 97.0.4686.0 with unsafe WebGPU flag enabled I get some errors in console that indicate that my browser does not support WebGPU.
Example: https://austin-eng.com/webgpu-samples/samples/helloTriangle
Is WebGPU Enabled?
TypeError: Cannot read property 'requestDevice' of null
Can you reproduce this behavior?
Recently (at least in 96), WebGPU is no longer behind a flag, instead it's now behind an origin trial. This means that you can register for a token and put it in the <head> of your webpage and it will enable WebGPU for all users.
To do this, go to: https://developer.chrome.com/origintrials/#/register_trial/118219490218475521, fill out the form, and retrieve your token. Note that you can also request a token for localhost for development. Then simply add <meta http-equiv="origin-trial" content={ORIGIN_TRIAL_KEY}/> to your webpage and if registered correctly, WebGPU will be enabled for not only you but everyone that visits your site.
If you are using JSX/React, use this: <meta httpEquiv="origin-trial" content={ORIGIN_TRIAL_KEY}/>
The difference is http-equiv vs httpEquiv.
As https://web.dev/gpu/#enabling-via-about:flags says, to experiment with WebGPU locally, enable the #enable-unsafe-webgpu flag in about://flags.
To check if WebGPU is supported, use:
if ("gpu" in navigator) {
// WebGPU is supported! 🎉
}
Caution: The GPU adapter returned by navigator.gpu.requestAdapter() may be null.
At the time of writing, WebGPU is available on select devices on Chrome OS, macOS, and Windows 10 in Chrome 94 with more devices being supported in the future. Linux experimental support is available by running Chrome with --enable-features=Vulkan. More support for more platforms will follow.
if you use chrome of canary, why not use the latest canary, as far as I know, satable version is already 108, the latest canary version is 111.
when you enable #enable-unsafe-webgpu in the lastest canary chrome. you can use ts code
let adapter: GPUAdapter;
let device: GPUDevice;
export async function getGpuDevice() {
if (device) {
return { adapter, device }
} else {
try {
adapter = (await navigator.gpu.requestAdapter())!;
device = (await adapter!.requestDevice())!;
} catch (e) {
alert('your browser don‘t support webgpu\n你的浏览器不支持 webgpu');
}
return { adapter, device };
}
}
good luck!
I'm looking through my GA logs and I see a Google Chrome browser version 0.A.B.C. Could anybody tell me what this is exactly? Some kind of spider or bot or modified http header?
The full user agent string probably looks something like this:
"Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.13 (KHTML, like Gecko) Chrome/0.A.B.C Safari/525.13"
This is most likely a bot, but it could just be someone running an automated script using CasperJS or PhantomJS (or even a shell script using something like lynx) and spoofing the user agent.
The reason it looks like that instead of something that says "My automated test runner v1.0" (or whatever is relevant to the author) is that this user agent string will pass most regular expression checks as "some version of Chrome" and not get filtered out properly by most bot checks that rely on a regular expression to match 'valid' user agent patterns.
In order to avoid it, your site bot checker would need to blacklist this string, or validate that all parts of the Chrome version to make sure they're all valid numbers. Even then, you can only do so much checking since the user agent string is so easy to spoof.
This seems to only happen in Chrome (latest version 31.0.1650.48 m, but also earlier), but since it doesn't always happen it's hard to say for sure.
When streaming audio stored in Azure Blob storage, Chrome will occasionally play about 30-50% of the track and then stop. It's hard to reproduce, but if I clear the cache and play the file over and over again, it eventually happens. An example file can be found here.
The error is pretty much the same as what's described here, but I've yet to see the problem on any files hosted elsewhere.
Update:
The Azure Blog log only gives AnonymousSuccess messages, no error messages. This is what I get:
1.0;2013-11-14T12:10:10.6629155Z;GetBlob;AnonymousSuccess;200;3002;269;anonymous;;p3urort;blob;"http://p3urort.blob.core.windows.net/tracks/bd2fd171-b3c5-4e1c-97ba-b5109cf15098";"/p3urort/tracks/bd2fd171-b3c5-4e1c-97ba-b5109cf15098";c377a003-ea6b-4982-9335-15ebfd3cf1b1;0;160.67.18.120:54132;2009-09-19;419;0;318;7663732;0;;;"0x8D09A26E7479CEB";Friday, 18-Oct-13 14:38:53 GMT;;"Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.48 Safari/537.36";"http://***.azurewebsites.net/";
Apparently you have to set the content type to audio/mpeg3
Here's how I do it:
CloudBlockBlob blockBlob = container.GetBlockBlobReference(fileName);
blockBlob.UploadFromStream(theStream);
theStream.Close();
blockBlob.Properties.ContentType = "audio/mpeg3";
blockBlob.SetProperties();
From here: https://social.msdn.microsoft.com/Forums/azure/en-US/0139d27a-0325-4be1-ae8d-fbbaf1710629/unable-to-load-audio-in-html5-audio-tag-from-storage?forum=windowsazuredevelopment
[edit] - This didn't actually work for me, I'm trying to troubleshoot, but I don't know what's wrong, going to ask a new question.
This mp3 only plays for 1.5 min and then stops. When downloaded, the file plays fully...
https://orator.blob.core.windows.net/mycontainer/zenhabits.net.unsolved.mp3
I am using Adobe AIR 3.8 and manually generating all of the OAuth calls for my application. Tracing out the user agent of the HTMLLoader that I am using for the OAuth calls in AS3, I get the follow:
Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en) AppleWebKit/533.19.4 (KHTML, like Gecko) AdobeAIR/3.8
I am able to get passed the user login portion and up to the part where they need to accept the permissions to move on. However, AS3 traces out the following error upon load complete of this page:
TypeError: Result of expression 'window.sessionStorage' [undefined] is not an object.
at https://apis.google.com/_/scs/abc-static/_/js/k=gapi.gapi.en.bI438WBuHt0.O/m=googleapis_client,plusone/exm=appcirclepicker/rt=j/sv=1/d=1/ed=1/am=IA/rs=AItRSTNuPHIoFBjGmVBeSqIsgUIKEsrbzA/cb=gapi.loaded_1 : 13
at https://apis.google.com/_/scs/abc-static/_/js/k=gapi.gapi.en.bI438WBuHt0.O/m=googleapis_client,plusone/exm=appcirclepicker/rt=j/sv=1/d=1/ed=1/am=IA/rs=AItRSTNuPHIoFBjGmVBeSqIsgUIKEsrbzA/cb=gapi.loaded_1 : 23
at https://ssl.gstatic.com/gb/js/smm_5a5968e7804546d31a076ff436e35b36.js : 149
at https://ssl.gstatic.com/gb/js/smm_5a5968e7804546d31a076ff436e35b36.js : 152
at https://ssl.gstatic.com/gb/js/smm_5a5968e7804546d31a076ff436e35b36.js : 149
at https://ssl.gstatic.com/gb/js/smm_5a5968e7804546d31a076ff436e35b36.js : 151
at https://ssl.gstatic.com/gb/js/smm_5a5968e7804546d31a076ff436e35b36.js : 151
at https://ssl.gstatic.com/gb/js/smm_5a5968e7804546d31a076ff436e35b36.js : 151
at https://ssl.gstatic.com/gb/js/smm_5a5968e7804546d31a076ff436e35b36.js : 151
This problem is similar to this problem which I assume has been resolved, since this original problem had the accept button disabled: TypeError upon authenticating user using Google OAuth 2
My issue has the start button enabled, but when you click on it, it just grays out and the HTMLLoader (internal AIR browser) goes nowhere. I notice that the option to select which of the user's circles are allowed to see the app activity doesn't render correctly as well. Here is a screenshot of what I see:
Authenticating via a normal browser using the generated OAuth URL works fine.
Also would like to note that the cancel button works just fine in AIR. When the hit cancel, the HTMLLoader redirects to the redirect url with "?error=access_denied" like it should.
Are you using the G+ Sign-In javascript library?
I try to inject several SIMBL plugins (e.g. Afloat and FScriptAnywhere) into Chrome and other applications.
It works fine on all other applications but not on Chrome. There I get this output on console:
01.09.11 13:30:15,911 SIMBL Agent: Google Chrome started
01.09.11 13:30:15,912 SIMBL Agent: app start notification: {
NSApplicationBundleIdentifier = "com.google.Chrome";
NSApplicationName = "Google Chrome";
NSApplicationPath = "/Applications/Google Chrome.app";
NSApplicationProcessIdentifier = 87543;
NSApplicationProcessSerialNumberHigh = 0;
NSApplicationProcessSerialNumberLow = 30412031;
NSWorkspaceApplicationKey = "<NSRunningApplication: 0x40092c060 (com.google.Chrome - 87543)>";
}
01.09.11 13:30:15,913 SIMBL Agent: checking bundle /Users/az/Library/Application Support/SIMBL/Plugins/Afloat.bundle
01.09.11 13:30:15,913 SIMBL Agent: checking target identifier *
01.09.11 13:30:15,914 SIMBL Agent: send inject event
01.09.11 13:30:15,956 SIMBL Agent: eventDidFail:'tvea' error:Error Domain=NSOSStatusErrorDomain Code=-1708 "The operation couldn’t be completed. (OSStatus error -1708.)" (the AppleEvent was not handled by any handler ) UserInfo=0x400877940 {ErrorNumber=-1708} userInfo:{
ErrorNumber = "-1708";
}
01.09.11 13:30:15,957 [0x0-0x1d00cff].com.google.Chrome: Google Chrome: OpenScripting.framework - can't find entry point InjectEventHandler in scripting addition /Library/ScriptingAdditions/SIMBL.osax.
I think the eventDidFail:'tvea' error can be ignored because I get it on all applications (although I wonder what it is).
However, I think the last error Google Chrome: OpenScripting.framework - can't find entry point InjectEventHandler in scripting addition /Library/ScriptingAdditions/SIMBL.osax is the relevant one.
What does it mean? What could it be?
Ah, it seems it was introduced as a feature by Chrome itself to blog SIMBL plugins because of stability issues.
http://www.conceivablytech.com/8990/products/google-stabilizes-chrome-for-mac-os-x-lion-adds-pulseaudio-for-linux
This is the patch for Chrome. And this is the bug report. Interesting, btw.; it uses mach_override from mach_star to patch the internal function _CFBundleLoadExecutableAndReturnError to add a check for blacklisted libraries.
I filed a bug report about a way to disable that CFBundleBlocker here.
I found a way to workaround the CFBundleBlocker in Chrome:
I patched SIMBL to work in /System/Library rather than in /Library. The patched version can be found here. Also, that patched SIMBL searches for SIMBL plugins also in /System/Library/Application Support/SIMBL/Plugins/. The SIMBL plugins must be installed in that directory because otherwise Chrome would also block them.