d3 supports IE9+, but nvd3 states it supports IE10+, yet I can find nothing in the commit logs stating a drop of IE9. In fact, a recent commit log states a fix for IE9.
So, what's the status of IE9 support?
According to Social Compare IE9 supports nvd3 only with aight. And if you can use npm it supports IE9.
Related
I'm using a Display Image Item with settings section set to 'BLOB Column returned by SQL statement'.
It shows the image (are big sized) without problems in Chrome, Edge or firefox but on IE it only shows a little black square with an X inside.
Any idea how to fix it?
Support for IE is deprecated since version 20.2, and even before there were features that did not work properly. My advice: don't use IE with Apex, if you can, use always other browsers which are properly supported and work without issues.
Display images might be one of those issues. Starting with Apex 18 this might be due to a problem with IE11 when using the X-Content-Type-Options:nosniff response HTTP header. The images from the display image items are not displayed correctly in IE11 because Apex is not able to define the correct mimetype.
This is reproducible in the case of BLOB Column Return by SQL Statement, which is exactly your case. You can confirm it using the console debug mode.
Notes
6.1.4 Support for Internet Explorer 11: Deprecated Support for Internet Explorer (IE) 11 is deprecated.
Starting with release 20.2, only the current and prior major release
of Microsoft Edge along with Google Chrome, Mozilla Firefox, Apple
Safari will be supported.
Deprecated means you can still use it, but support will ultimately be removed for it. Also as Microsoft has removed IE as its standard browser, replacing it by Edge, it is likely you will always have unexpected behaviour in this browser.
We all know that for security reasons and compatibility with legacy applications, many companies still use IE in order for those applications to work properly. However, using it with Oracle Apex is always a bad idea.
I have a problem with ajax components hx:ajaxRefreshSubmit and hx:ajaxRefreshRequest on IE11. Both of them are working only on the first submit - request.
I use the latest version of JWL and Portlet Bridge (jsf-ibm.jar v 3.1.20, jsf-portletbridge.jar v 3.1.19).
Ajax works on all browsers (IE9, IE10, latest Chrome, latest Firefox, Microsoft Edge) except on IE11.
Has anyone managed to solve the problem?
Our JSF1.2/JWL project has also been pushed onto IE11. Running the page in compatibility mode seems to solve our issues.
I also found a solution which involves changing the JSP with a directive to work as IE<11 on this page IBM Developer Works although I haven't tried it yet.
I prefer google chrome in almost every way above IE10, but one thing I hate is that fonts just look much better in IE10. This especially visible with small math fonts. They look like pdf quality in IE10.
After searching a little bit, I found out that this is because IE10 use DirectWrite in windows 7/8 for font rendering. I was searching if chrome will support this in the future and I found this information:
Apr 24, 2013:
An update for everyone that's watching this one:
Our Windows font rendering is actively being worked on. Basic support
for DirectWrite is now in Skia (to update from comment #13). At the
same time, GDI was very deeply embedded in the Windows WebKit port and
is still being rooted out. We hope to have something within a
milestone or two that developers can start playing with. How fast it
goes to stable is, as always, all about how fast we can root out and
burn down any regressions.
We'll update the thread here when it's available behind a runtime flag
for y'all to try out.
Oct 8, 2013
The following revision refers to this bug:
http://src.chromium.org/viewvc/blink?view=rev&rev=159071
Changed paths: M http://src.chromium.org/viewvc/blink/trunk/Source/core/platform/graphics/skia/FontCacheSkiaWin.cpp?r1=159071&r2=159070&pathrev=159071
M
http://src.chromium.org/viewvc/blink/trunk/Source/core/page/RuntimeEnabledFeatures.in?r1=159071&r2=159070&pathrev=159071
Add runtime flag for using DirectWrite on windows
Add runtime enabled feature for using the DirectWrite skia backend on
windows.
BUG=25541 R=bungeman#chromium.org, eseidel#chromium.org
Review URL: https://codereview.chromium.org/26335002
I don't even know what a runtime flag is, but this sounds to me that it may be possible to somehow enable directwrite in chrome. Is this true ? Or should I wait a little longer before I can use directwrite font rendering in chrome ?
Sadly not yet (as of 2013-10-31, no Chromium channels supports this feature out-of-the-box).
If you look at the latest RuntimeEnabledFeatures.in, DirectWrite doesn't have any status assigned to it. According to Blink document, users cannot enable a feature via about:flags unless status=experimental is assigned.
But hopefully soon, so windows users may have a better time with web fonts :)
Update 2013-11-16: with latest issue 25541 comment, it seems we are very close to be able to enable DirectWrite in Canary.
Update 2014-01-04: Canary build now has a command line switch that can enable DirectWrite font rendering, but disabling sandbox mode are required (not safe for everyday browsing). There are also a few font rendering problem associate with it. Hopefully they can get them fixed and add this feature to about:flags soon.
Update 2014-05-09: latest Canary build (m36) now has proper support for DirectWrite within sandbox mode (implemented via issue 333029), which means developers can enable DW directly by going to about:flags#enable-direct-write. As for consumers, Google is targeting release on m37.
Update 2014-08-09: Chrome 37 beta enables DirectWrite by default, expect Chrome 37 official release to have it by default as well.
Update 2014-08-31: Chrome 37 stable release has DirectWrite enabled by default! Just note that users can still turn it off at about:flags (some of them use MacType instead).
Chrome 35 (beta) comes with an option to enable DirectWrite for Windows font rendering. Paste the following command in your address bar and click enable:
chrome://flags/#enable-direct-write
Reference: http://www.reddit.com/r/web_design/comments/22q9r9/chrome_35_beta_has_finally_fixed_windows_font/
It's currently in development for chrome on windows.
http://www.chromestatus.com/features/4725550652325888
Update: on August 26, 2014, Google updated the stable version of their Chrome browser to version 37.0.2062.94 on Windows, OS X, and Linux. With this release, Chrome move from Microsoft's Graphics Device Interface rendering method to Microsoft's DirectWrite text rendering API. Switching to DirectWrite has been requested for years by users on Windows, and Google has stated that it took significant rewriting of their font rendering engine which is why it has taken so long.
It's in Chrome as a flag as of 33 (and as of this time of writing), however from what I understand you still need to run it with the sandbox disabled via the command line --no-sandbox. This is not a recommended action for everyday use. You can enable the rendering flag, but it will only change if sandboxing is disabled.
(I would have added this as a comment to #chickenbooze, but I've switched SE accounts and don't have enough reputation yet :)
I am not sure if this is bug on chrome but my last td on the grid is not displaying properly.
Below is screen shot if using FIREFOX
While displaying on CHROME is just like this. The width settings is 80px. Temporarily I align it left to at least show the content.
{name:'act', index:'act', width:80, align:"left"}
Any experienced with this? my chrome version is 19.0.1084.56 m
What version of jqGrid are you using? The team recently released version 4.4.0 which corrects some of the display bugs that were showing up in Chrome viz a viz Internet Explorer/Firefox. I upgraded and many of these display anomalies went away.
The most recent version of Firefox has messed up our internal wiki layout so that the left bar menus are displayed below the content on all pages now.
I've tried using multiple resolutions and window sizes and the problem persists so that doesn't appear to be the issue.
There are no problems with Chrome or IE however.
A screenshot of the problem is attached here for you to see.
You're using an old MediaWiki version. It does UA sniffing and sends different code to different browsers, relying on bugs in some of the browsers to make the code sent to them render correctly.
Firefox 9 removed a nonstandard property that only Gecko used to implement. MediaWiki was using that property to decide that the rendering engine was Gecko. With it gone, MediaWiki now decides that you're using kthml and sends CSS rules tailored to khtml bugs... but Gecko happens to not have those bugs. So the rendering ends up wrong.
Your options are to either update to MediaWiki 1.16 or newer (which you should do anyway, because your version is not getting security fixes anymore!) or wait for Firefox 10 to come out, because chances are that will restore the nonstandard property because too many sites were sniffing for it.
See also https://bugzilla.mozilla.org/show_bug.cgi?id=683151 and https://bugzilla.wikimedia.org/show_bug.cgi?id=31807 for more info.