I have a Microsoft Word 2016 Add-in that (like all Office.js Add-ins) uses Apple's WebKit as the embedded browser.
(On Microsoft Word 2016 for Windows the browser is IE11 of all things).
On El Capitan my Add-in is throwing an error - which is nearly impossible to debug...at least given what I know. Specifically 10.11.6.
Everything works fine on Sierra.
I've traced the issue to, potentially, my use of localstorage to keep and reuse a couple of values...
Does Apple WebKit embedded support the use of localstorage? Maybe there's some sort of permission or initialization required?
Is there any way to troubleshoot embedded webkit? The solution works fine on Safari/Chrome etc.
Are there any other differences between webkit on El Capitan and Sierra?
Yes, WebKit (at least for 10.11.6) supports localstorage.
I traced my problem to the use of 'const' while in 'use strict'...
I was using a code snippet from Firebase/Google (for authentication across all my apps/websites) that declared a variable using “const”.
In “use strict” this is not allowed in older versions of WebKit. It’s been fixed, which is why Sierra was okay (I guess).
See https://bugs.webkit.org/show_bug.cgi?id=161464.
But it threw an error on 10.11.6 and (I guess) earlier.
Here is the crucial bit of info: how to turn on debugging for WebKit (when used as an embedded browser):
Run the following command using terminal on your Mac:
defaults write com.Microsoft.OsfWebHost WebKitDeveloperExtras -bool true
Related
currently I'm testing my website in which I'm getting a validation error message which should not come ideally.
The same things works fine in Windows Safari, but it fails in Mac Safari. Is there any difference in both the browser on how they handle Javascript and Ajax calls?
Thanks in adv.
Yes, in terms of interaction with the core systems - but the display and rendering of HTML, CSS and JS are identical as they use the same engine, WebKit. To read more about WebKit check this wikipedia article.
https://en.wikipedia.org/wiki/WebKit
It may be some sort of caching issue, I would suggest trying a private browsing session or clearing cache to test your JavaScript.
See also this question which talks about the rendering engine differences (of which there are none)
Differences between Safari for Windows and Safari for Mac
I need to test javascript on IE8 but since I updated I cannot install IE8. What do developers do in this situation?
The most reliable way is having multiple virtual machines installed on your computer (or on a testingstation) that run different windows versions and IE versions.
There is no way to install IE8 or multiple IE versions at the same time on one windows installation.
You find all windows versions and IE versions here and also some instructions how to set up the virtual machines.
Another way is to use the tool IETester, which only runs on windows and kind of simulates different IE's. It never really felt reliable to me.
There are also different companies, which provide multi-browser testing suites. They allow you to remotely test browsers (including IE8) remotely on their servers. For example Browserling or Browserstack.
Use a VM! Get something like virtualbox and you can get the box from Microsoft https://dev.windows.com/en-us/microsoft-edge/tools/vms/windows/
You can use the emulator built into 11 but know that it's not a direct emulation and isn't the real thing. A VM will create a new machine that is running a paired down version of windows and the browser.
If you open the developer tools there is a button on the top right corner which allows you to run the browser as an older version of IE:
I am using PhantomJS (headless end to end testing),selenium webdriver,grunt(task runner) for my application testing. My requirement is that the application should be compatible with IE-9. I have to do headless testing because I'm using jenkins for continuous integration.
How do i make sure that my application will run perfectly on IE-9
while testing on phantomJS ?
You can't use PhantomJS for testing compatibility with Internet Explorer, because it is a Webkit browser.
Since you're using Selenium, you should be able to use the IE WebDriver.
Some thoughts on why you can't even simulate IE in PhantomJS:
They are built on different base technologies. They use different rendering engines and both have different bugs when it comes to adhering to W3C specifications.
JavaScript bugs may be simulatable, but this requires you to go ahead and fix all bugs that PhantomJS has in comparison to your specific IE version by exchanging the implementation of some browser APIs. You would also need to introduce some bugs that are present in your IE version, but not in PhantomJS again by exchanging implementation.
CSS bugs can only be introduced if you change the WebKit implementation and compile it again. You would have to find them first.
Great, you have effectively reverse engineered IE.
I am getting a very weird kind of error with IE9. When I use a DOMParser from within a jsp page on localhost, it runs perfectly fine and gives the proper result.
But Shockingly, when I use DOMParser inside a normal HTML file (Not on the server. From the file system), I get this annoying message of "DOMParser is undefined" .. What is this and how can I make it work? Thank You.
P.S. It works fine on FF and Chrome
I would say that this is almost certain to be the browser running in compatibility mode when browsing local URLs.
You can check this by opening the dev tools (press F12) and looking in the top right corner; if it says it's in IE7 mode, then you've found the problem. Switch it back to normal IE9 mode and it should come right.
IE7 didn't support the DomParser object, so if IE9 is in IE7 compatibility mode, it's natural that it will stop supporting it too.
Ok, so that's what it's doing. But why is it doing this? There is a config setting in IE (both IE8 and IE9) which specifies that the browser should fall into compatibility mode when browsing sites on the local intranet. The reason for this setting existing is to allow companies who have internal sites designed for older versions of IE to upgrade to a new version without breaking those sites. It's intended to make like easier for corporate types who would rather not spend money fixing something when the broken version is good enough.
But it's a pain in the rear for the rest of us.
Obviously, if your site is on the public internet, it won't be affected by this flag, except when you're trying to work on it from localhost on your own PC. Therefore, the solution for you is to simply turn off this config setting in the browser and forget about it.
Of course, the fact remains that users of IE7 will still have this problem with your site, as their browser doesn't support the feature you're using. You could just drop support for IE7, and tell those users to upgrade. But if you want to support IE7 users, I believe that Dean Edwards' IE7.js script allows the browser to emulate this feature (along with a bunch of other stuff that Microsoft forgot).
Hope that helps.
I received this error, "DOMParser is undefined", on IE9 and it turned out to be an add-on that was disabled.
Name XML DOM Document
Publisher Microsoft Corporation
Status Enabled
Tools – Manage Add-ons – Microsoft Corporation
I have an javascript application which I created on windows for windows browsers and released on the internet.
I bought an iMac last week.
And I found the application can run normally on mac, too.
I need to maintain and modify the application in the future.
And I want it to run on both windows and mac.
If javascript of firefox and chrome of mac have complete compatibility against those of windows,
I need neither windows machine nor windows in the bootcamp.
Do javascript of firefox and chrome of mac have complete compatibility against those of windows?
Or should I test the application not only on mac but also windows for every update?
I don't want to do that if possible.
JavaScript in Chrome / Firefox / Safari should be the same on OSX and Windows provided you are using equivalent versions between OSX and Windows. If you find any differences, then you'd probably be best to file a bug with them.
Mind you, I am talking about just pure JavaScript. If you are worried about how it displays, then it will probably be different. Browsers render certain components differently depending on the operating system; such as the default font, the chrome of the buttons, etc.
You should be more concerned about the version of the browser when testing, not the platform it is running on.
Platform-specific bugs are few and far between, but the are possible. Yahoo tests on multiple operating systems, not just multiple browsers. It's a question of how careful you want to be. For most sites, you can probably assume that the OS won't make a difference.
If what you're saying is accurate, then it was a mistake in the design of the JavaScript. You should have been testing for particular JavaScript capabilities, but it seems in you were testing for browser names.