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 :)
Related
When attempting to profile a webpage using Chromes Dev tools, since the most recent update most performance profiles load something like the attached image. All the data is crammed up against the right side of the timeline and now there are negative milliseconds included in the timeline... which doesnt make sense. Is anyone else having this issue since the most recent chrome update? I cant find anything in google docs.
I use the 'Record' and 'Start Profiling and reload page' buttons on the performance tab a lot and also have the bug similar to yours on Windows platform since Chrome v.90 (Chrome v.92 also have this bug), Linux versions are not affected.
As a temporary solution, you can downgrade Chrome to any version below 90 (configure your system to prevent Chrome updates): Chrome x64 v.86 (other versions/platforms)
If you need to use the latest Chrome version, you can install an older Opera or Opera GX (e.g., LVL2 ver.68) to use it with non-bugged performance tab (newer Opera versions also have this bug because they also have an updated Chromium engine)
After updating Firefox to version 50.0 my Firebug opens the default developer tools. The original Firebug doesn't work anymore.
I have always preferred Firebug as my default debugging tool. I want the original Firebug back in Firefox 50. How can I do that?
Firebug does not work anymore once multi-process Firefox (separate processes for the Firefox UI and the websites) is enabled. See the related post in the Firebug blog.
You may be able to reenable Firebug by setting the preferences browser.tabs.remote.autostart, browser.tabs.remote.autostart.1 and browser.tabs.remote.autostart.2 to false via about:config. Though at some point this preference will be removed.
So, you are advised to use the Firefox DevTools instead. I am writing a migration guide on MDN. Firebug features that are not in the DevTools are covered in a Firefox bug.
First remove new version of "firebug" and download old version of "Firebug(2.0.17)" from following URL:
https://addons.mozilla.org/en-US/firefox/addon/firebug/versions/
Uninstall Firefox completely including deleting the Mozilla folder within your APPDATA.
Then reinstall Firefox and add both Firebug and FireQuery.
After that everything should work as before.
You can also go on Help -> Troubleshooting Information -> Refresh Firefox and install Firebug through http://addons.mozilla.org/
For all the folks out there, there is a good news..!! Firebug works great on these two Mozilla based browsers.
Cyberfox & Palemoon
Both are forks of forefox that uses code before the implementation multi-process. Cyberfox uses the more recent code fork compared to Palemoon.
Both browsers are well maintained and updated regularly.
Cyberfox announced its death on March 2017 but its still actively maintained [as of Dec 2017] and I still get update.
Both browsers support cross platform windows / Linux, on Linux you should have 64 bit distro to use cyberfox. Palemoon on the other hand works great on both the bits.
Our web browser plugin has worked in all IE versions and still works fine in IE9 and IE10 but in IE11 the plugin is not even recognized and listed as an add-on. It's as if IE11 no longer supports ActiveX.
NOTE: this questions is asked as the developer of the plugin and not the end-user who might need to correct IE settings. So suggestions for how to detect ActiveX or how to adjust a browser settings to allow ActiveX are useless here.
We assume that what we need to do is make adjustments to the ActiveX structure so that IE11 on Windows 8 approves the plugin so that it can be available to the user at their discretion, ie: list it in the Add-on Manager.
A sample project and test page can be downloaded from here - http://addmine.com/temp/EPM_project.zip
Surely there is a workaround but what do we need to change?
As of IE11, add-ons are supported only for IE on the desktop. If you're running the Windows Store experience of IE, then your statement about IE11 not recognizing the plug-in is absolutely correct. This article shows how you can have this experience prompt the user to open the page in the desktop experience of IE, which will support your plugin.
Having said that, it's entirely possible that you do change your plugin to support changes to the Windows 8 security model. Here are a couple of links to get you started:
Supporting enhanced protected mode (Note that this is part 1 of a four-part series)
IEInternals: Understanding Enhanced Protected Mode
IE Blog: Enhanced protected mode
Hope this helps...
-- Lance
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.
I am running Firefox 4 beta for testing, and unfortunately Google hasn't updated their Gears extension for Firefox 4. At this point, it even seems that Google might not update Gears for Firefox 4. Do you guys know of any trick to get Gears to run on Firefox 4?
(For reference, here is where you can download the OS X XPI for Gears.)
Google have explicitly deprecated Gears; they no longer support it (as of about a year ago!).
They have switched to focus on HTML5 and other related new browser features. In effect they're saying that all the functionality provided by Gears can be done using HTML5.
Here's a link to an article about them dropping it (but there's plenty of others if you google for it):
http://latimesblogs.latimes.com/technology/2009/11/google-gears.html
The down-side is that not all browsers do support all the HTML5 features that are needed to replicate the Gears functionality, so by deprecating it they've cut off support for some browsers. Chrome is fine, of course! But the other browsers are catching up - certainly Firefox 4 should be fine.
A lot of the functionality provided by google-gears is becoming part of html5 - firefox has implemented local storage since 3.5.
Modernizr provides api detection - but not abstraction - I imagine there may be some out there on the internet (Google Gears / HTML5 has only recently appeared on my radar). So far I've not found any way for an html5 app to create a desktop shortcut though.
Update:
See also:
http://www.phonegap.com/
https://github.com/zefhemel/persistencejs
http://code.google.com/p/webstorageportabilitylayer/