I've read through dozens of SO threads on how to get orientation on Safari browsers. Almost every single answer recommends using window.orientation. This is documented as the recommended method here, since screen.orientation is not available on Safari, which is indicated on the MDN docs (even though it's marked as deprecated).
Great, so it just seems I have to check window.orientation if Safari is the detected browser. But that always returns undefined. I've tried checking all available functions when I inspect window inside a Safari browser, but there's no mention of any function that contains the word "orientation" in it.
I've inspected the attributes available within window.screen, but there is no mention of anything related to orientation or even the angle of the screen.
Cool. So how does one go about determining the orientation on this amazingly developer-friendly browser? I'm open to super obscure hacks, as that's been my go-to for most Safari functionality in the past.
Related
What technical requirements or methods do I need to implement to make my app appear in the URL browser under "app Store" suggestions in safari? This is what happens if I am typing in "slack" straight into the url bar of safari. It also appears if I haven't installed slack at all --> that's what I would like to implement as well.
Is that a auto suggestion-tool by safari which we can not influence at all?
Any hints to make that happen? Here's an image of Slack on Safari:
Thanks a lot!
These suggestions are known as Safari or Siri Suggestions, and appear to be controlled solely by Apple/Safari itself.
One source on Quora says,
“Siri Suggested Websites” are search results that come directly from Apple’s own search engine, based on websites they’ve crawled and indexed. It’s not based on your search history (or even anything you’ve done with Siri).
I wonder if your app would show up as a Suggestion if it was unique or popular enough in Apple's search indices...
I am displaying a set of properties on Bing map. It works all fine in Chrome, FireFox, IE, and Safari on Windows (version is 5.1.7 - their latest version for Windows). But it doesn't work in Safari 7 on Mac.
When displayed correctly, all properties are located on a green residential area. But on Safari 7, all properties are displayed on the far left of that area - on a totally wrong location. Also, the larger left part of the map is blank (there is no map!).
I saw a similar post Bing Maps Issue on Safari 7. The left part of their map is also blank. The problem there seems not solved. I followed Microsoft's guideline (meta, CSS position/width/height etc), none of them work.
I suspect that's a Bing bug? Or a Safari bug?
Sorry I don't have enough reputation to post images...
Now that I solve the problem, I confirm that this is NOT a bug of Safari or Bing.
the <div> that load the the map is embedded in many other divs, panels, fieldset, Telerik ajax panel, RadTabStrip etc. You have to remove some of divs, and also some styles of divs to make it work. It's tricky, you have to do many tests to finally pin down which element caused the problem and remove that element.
I took me several days to figure this out.
I am using FireBreath to create a cross browser plugin which makes use of some native libraries for the respective platform (some .NET based DLLs for Windows and Objective-C based dylibs/frameworks for Mac). Native libraries display UI screens. In order to improve usability, if the user has a multi/extended monitor setup, i would like the native UIs to appear on the same screen as the browser window is currently on.
If an identifier to the monitor with the browser window can be retrieved, that can be passed down to the native components which can be configured to display their UIs on that monitor. I have used FireBreath's getWindowPosition() method to get the rect coordinates of the plugin and used that info to identify the correct monitor in the Windows platform.
However, the coordinates returned in Mac seems to be always 0 (or 1) irrespective of monitor on which the browser window currently resides. I understand that we have to configure an event model and a drawing model in order for this to work in Mac. I have tried following event/drawing model combinations without much success.
1) Cocoa/CoreGraphics
2) Carbon/CoreGraphics
Any help in this regard is much appreciated. Also please do share if there are other approaches to achieve the same. What i want to achieve is to identify the monitor on which the current active browser window resides in Mac. I am unsure at this point, but it maybe possible to achieve this at Objective-C level (without any changes at FireBreath level). Also please note that i want to support Safari, Firefox and Chrome browsers.
You won't like this answer, but simply put you can't do that on Mac. The problem is that with CoreGraphics you are only given a CGContextRef to work with, and it doesn't know where it will be drawn. It was technically possible in older browsers to get an NSWindow by exploiting some internal implementation details, but many browsers that's no longer possible and it was never supported.
Other drawing models are the same; CoreAnimation you have a CALayer but it doesn't know which screen or monitor it is drawn to. I personally think it's a bit annoying as well, but I do not know of any way to find out which monitor your plugin is rendered to, particularly since most of them actually copy the buffer to something else and render in a different process.
I did manage to come up with a workaround and i am just replying here for the completeness of the thread. As #taxilian explained, it is not possible to retrieve plugin coordinates using the window reference. As an alternative approach, Javascript 'Window' object has 2 properties called 'screenX' and 'screenY' that return X and Y coordinates of the browser window relative to the screen. If the user has an extended monitor setup, these are the absolute coordinates with respect to the full extended screen. We can use these values to determine the monitor with the browser window (if the X coordinate is outside the bounds of the primary monitor's width, then the browser should essentially be on the extended monitor). We can retrieve DOM properties from Firebreath as explained in the following link:
http://www.firebreath.org/display/documentation/Invoking+methods+on+the+DOM
Having a bit of a conundrum with cross-browser compatibility and could use some help.
Our live version linked to below, seems to work perfectly fine on most browsers, including IE9+, but the controls appear hidden in a non-emulated stock out-of-the-box version of IE8:
http://dig-houston.com/portfolio/inspiron
Here's a screenshot of what it looks like in IE8:
At one point, I was still able to slightly see the controls sticking up from the bottom (and click) which lead me to believe something had gone awry in absolute positioning or the rejection of newer CSS techniques. But as my fine tuning progressed and heights were adjusted, I believe the controls were hidden further out of view outside the box.
That being said, I think this is just a CSS issue, but haven't targeted the right styles being applied yet. To anyone else out there using Video.js
I've tested in Chrome, do I need to test in Safari?
I've noticed Safari handles Asian characters better than Chrome.
Also Chrome and Safari rely on the same Webkit for rendering pages, but their Javascript engines are totally different, so if you use Javascript in your pages you need to check both.
Browsershots will send you screen shots of your page in just about every browser ever made.
Safari uses 'mac' fonts, but Chrome would use 'Windows' fonts. I've noticed that there can sometimes be problems where using a font like Arial, it shows up fine in firefox/chrome/ie, but on Safari, it can cause a line to wrap because the font is slightly bigger.
Yes, but only for your fonts and JavaScripts.
I have noticed some of the default fonts are smaller on Safari then Chrome, also Chrome uses the V8 JavaScript engine which has caused some people problems, especially if you have a lot of form logic.
yes.
Oh, you wanted more detail? Simply, Chrome and Safari have a lot of different features in their implementations, and Safari is pretty widely used. If you expect the general public, and particularly those of us who work on Macs, to use your application, it would behoove you to test in the Safari browser.
Yes, safari and chrome even though they are using webkit the two versions of webkit that are being used are significantly different. So you need to restest.
In a word, No. You can't assume that because it works in one it will definitely work in all cases in the other. Sure, 99% of the time, it might be the same - but 99% isn't 100% - at least, it wasn't last time I checked. Call me a pedantic git if you like.