I have an angular app that I would like to force users to view in "portrait" mode even when rotated in mobile browsers. I'm attempting to use the screen.orientation API, but I'm getting the error:
"Uncaught (in promise) DOMException: screen.orientation.lock() is not available on this device."
The short version of code that I've used in trying to debug in the console is:
screen.orientation.lock("portrait")
This returns the error provided above. I have tried this on both MS Edge version 107.0 and modern versions of chrome, on different machines and devices and all yield the same result. In looking through other articles all are old posts and point to use this API, which seems as if this is no longer supported by modern browsers.
Is there another way to do this, or would I need to use CSS to render the page differently when detecting a change state of the orientation?
Related
I am getting this error on sentry. I don't know how or why the next/router is redirecting users to the same page, it is happening on some browsers, and on some browsers, it is working just fine.
Tags
{
"routing.instrumentation": "next-router"
}
Operation - pageLoad
It looks like this has to do specifically with the Vivo OEM browser.
The current Vivo is based on Chrome 87 (2020).
I ended up on some Chinese dev blogs etc detailing similar errors with the same message.
Those seem to have been due to Vivo not handling new ES6 features. Not certain exactly what is not supported in the current version that's causing this.
We're looking at adding filtering around the <anonymous> file in the stack trace since (as far as I can tell) that's always 3rd party scripts throwing up.
For some reason the iPhone devices are never able to load the url requested by Protractor, they always show a blank page. It tries to load the url several times and then gives up.
The other BrowerStack devices all seem to work, including Windows, Android, and Safari/Macbook.
Has anyone encountered a similar problem?
For reference, we're using Protractor v2.2.0 (have not been able to updated because we're stuck in an old version of NodeJS, but we could try if that is the cause of the issue).
I have a hybrid application built using a WKWebView. I have gotten around the loading local files issue, but I am having trouble loading an AngularJS application from local files. I am getting the following error:
Cross origin requests are only supported fro HTTP.
With Android I was able to update setting on the WebView control to allow this from file:// schemes. Is there anything similar that I am missing in iOS? Or another solution?
I am using XCode 6.3 (6D570)
This is a known issue with WKWebView in iOS 8, and I suspect that's why UIWebView remains undeprecated.
I haven't had time to use the betas yet, but my only suggestion is to give the latest Xcode 7/iOS 9 a shot, and use the new WKWebView API
- (WKNavigation * _Nullable)loadFileURL:(NSURL * _Nonnull)URL allowingReadAccessToURL:(NSURL * _Nonnull)readAccessURL
which would ideally let you pull in other HTML files as templates in the readAccessURL that you provide.
Please file any bugs you see in the latest beta. Apple is way too slow to move on the issues in WKWebView.
If you just need the Angular app to work now, then you'll need to switch to UIWebView, which is confirmed to work with angular-based webapps stored on the device.
I have an Angular App that we recently upgraded to AngularJS v1.3.8 and now we get intermittent "Aw, Snap" crashes in chrome. But the app runs fine in other browsers and on certain computers.
Any time we encounter this error a refresh fixes it immediately.
We have explored many options trying to figure out the root cause of this issue:
- Verify memory profile
- Verify CPU profile
- Verify Hardware Acceleration on/off
- Verify minified/unminified AngularJSv1.3.8
When we reverted back to Angular v1.2.7 we no longer see this crash. We have isolated this change and is the ONLY change between revisions.
Has anyone experienced this as well? Or does anyone know of any reasons for this? Or any compatibility issues that could lead to this error?
Error encountered using Chrome Version 39.0.2171.95 (64-bit)
For us, this occurred when we did an $injector.invoke inside a responseError interceptor. It seems that it is sensitive to that.
Over Christmas I implemented some code to open a channel to my App Engine application using the channel API and it was working fine.
I recently returned to the code and find that it is broken, and the problem seems to lie in talkgadget that the client code is trying to load into a frame.
I took a snapshot of the code returned by /_ah/channel/jsapi on December 21 and I am comparing it to today's code.
When the older version tried to get talkgadget.google.com/talkgadget/d?token=[my-token] it was hardcoded to use http. Sensibly enough, the code was later changed to check the page's protocol in document.location and adapt to cases where https is used. The problem now is that when running in a chrome extension it grabs chrome-extension: as the protocol and naturally the channel fails to open in the extension.
Setting the base of the background page to my appspot URL does not change document.location, although I had some vague notion that it should. (Not sure what the standards say.)
Is there a workaround for this? One thought was to create my own iframe loaded from my site, but then it will nest the actual channel iframe, complicating things.
I wonder if Moishe or someone else on the App Engine team could comment on this. It seems like the this is a bug and the code should take into chrome extensions either by testing for the protocol and searching for a base tag as an alternative, or provide some way to configure this through the javascript object.
Yep, this is a bug. There's a fix submitted, and it's in the process of rolling out to production; it'll probably be out in about a week.
In the meantime, your idea of an iframe embedded in the extension should work.