Firefox 39.0 released
mozilla.orgI love that the Fetch API is happening (has happened!): https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API
fetch(url).then(data => ...)
Guess nobody told them,
https://bachelorburnbook.files.wordpress.com/2013/07/image.p...
We've been making that joke internally at Mozilla for at least a year.
fetch looks nice on the surface, but you can't cancel a request. is there even a timeout?
how do I use it with the yield keyword?
> Disable use of RC4 except for temporarily whitelisted hosts
This is the one which has the greatest chance of giving people a headache. For instance, one of the biggest banks here still uses only RC4 for its online banking site. Its top-level hostname and a few of its auxiliary hostnames are on the whitelist, but there's no guarantee that all the RC4-only auxiliary hostnames it might use for some of its functionality are on the whitelist.
Good. Breaking their websites is the only way some people will fix their broken security.
YES. Force them to upgrade their weak sites!
Which unfortunately costs time and money. Whilst yes, they should be up to date and secure, banks are pretty big businesses and require more time.
One day they'll catch up.
Banks handle everyone's money and are high-profile targets for compromise over the network. As such, they should be obliged to keep current with best security practices as the technology evolves, not lag far behind these.
But that's the inherent problem; these companies are still setup for a bureaucracy that works fine in a particular area of business, but completely crumbles under the new rules of the technological age. We shouldn't be apologetic for their resisting of change, but rather pushing them to take a long hard look at what needs to be reorganized to fit into the new paradigm.
Banks, of all businesses, should be concerned about online security, for real protection and for appearance of caring for their customers' peace of mind. Mozilla telegraphs these browser changes months in advance.
Malicious crackers aren't going to wait.
After the CVE score for BEAST and RC4 got adjusted and the RFC 7465 was introduced I've seen some payment systems update their system quite quickly (in a matter of days), and if they didn't they'd probably fail their next PCI audit: https://news.ycombinator.com/item?id=9198889
Perhaps it helps if you write your payment site operator/bank private emails asking them to allow other ciphers beside RC4, mine looked like this (actual site name removed):
According to Qualys SSL Labs the site **** [2] only supports the RC4 cipher, and thus is not RFC 7465 compliant [3], and Google Chrome qualifies the site as "Your connection to **** is encrypted with obsolete cryptography." The site **** is even worse [4], it uses only 768-bit DH key exchange in some situations (instead of 2048). There is an online tool [5] that you can use to generate/compare configuration for popular web-servers, using the intermediate level is recommended [6]. For your information I sent a similar email last year to **** and they have fixed their problems, and get a nice 'A' grade from SSLLabs now. Apparently this use of RC4 all comes down due to a mistake in NIST's classification of the severity of the BEAST vulnerability [7], but both Google Chrome[7] and Mozilla Firefox[8] are trying to avoid the use of RC4 completely, and mitigating the BEAST vulnerability is no excuse for not providing good ciphers (in addition to RC4 if you must) when my browser supports TLS 1.2 with AES-GCM which is NOT vulnerable to the BEAST attack. I suggest you to include the Qualys SSL Labs test when testing sites for PCI-DSS compliance, they are usually quite good at reporting the latest TLS vulnerabilities for a server. [1] http://www.visaeurope.com/media/images/pci%20dss%20validated%20web%20listing%20march%202015-73-18412.pdf [2] https://www.ssllabs.com/ssltest/analyze.html?d=**** This server accepts the RC4 cipher, which is weak. Grade capped to B. Certificate uses a weak signature. When renewing, ensure you upgrade to SHA2. [3] https://tools.ietf.org/html/rfc7465 [4] https://www.ssllabs.com/ssltest/analyze.html?d=**** This server supports insecure Diffie-Hellman (DH) key exchange parameters. Grade set to F. Certificate uses a weak signature. When renewing, ensure you upgrade to SHA2. The server supports only older protocols, but not the current best TLS 1.2. Grade capped to B. This server accepts the RC4 cipher, which is weak. Grade capped to B. [5] https://mozilla.github.io/server-side-tls/ssl-config-generator/ [6] https://wiki.mozilla.org/Security/Server_Side_TLS [7] https://code.google.com/p/chromium/issues/detail?id=375342#c30 [8] https://bugzilla.mozilla.org/show_bug.cgi?id=1088915 [9] https://www.ssllabs.com/ssltest/analyze.html?d=****Sadly the 768-bit DHE is hardcoded into older versions of Java, which is why I suggested to them that they raise the limit to that instead of 1024-bit for now.
Actually, the security.tls.unrestricted_rc4_fallback is still true by default.
Surprised by the inclusion of "CSS Scroll Snap Points": https://developer.mozilla.org/en-US/docs/Web/CSS/scroll-snap...
It basically allows to do scroll hijacking [1] without any JavaScript, just like this: http://blog.gospodarets.com/demos/scroll-snap-full-screen/
I'm torn.. I dislike scroll hijacking and in a sense don't want support for this practice, _but_ at the same time I assume this will never go away and then this seems less hacky and easier to make it work without ruining use on various input devices and settings.
For example, I tried the demo and saw how the pages jumped to the nearest page if I middle click and pulled down to go half way. Corner cases or anything more complicated than simple wheel flips often don't seem to work if you hack your own solution. Now the browser seems to have a much better idea of what's going on. So.. That's nice. We'll get hijacks but at least they seem to be much more robust? But at the same time I hope this won't make more designers hijack scrolling or go overboard with this. :\
People experimented with new ways of handling user input (as they have for decades), found that it was a good way to layout some pages, and then complained to browser vendors that doing it in JS sucks. CSS snap points is just a way to make the experience better for developers and users. That's exactly how the Web should work.
Personally I think CSS is "style hijacking" — the Web really is about the text, not the colors.
The Firefox/native version of the page works much better than the jQuery version. Both are a little bit janky with touchpad scrolling, but the native version allows you to scroll to the next page before waiting for the animation to finish. With a mousewheel, the native version is far better and acts as you expect; the jQuery version just feels like a terrible hack and doesn't let you scroll where you want, when you want.
Woah I did not expect it to work that well. I always hated scroll-hijacking webpages, because ~1% of them did it right.
As much as the effect can be irritating, Firefox lets you over-scroll before snapping which is a much better experience compared to that fallback jQuery plugin.
this is in Safari 9 as well. https://developer.apple.com/library/prerelease/mac/releaseno...
If all your passwords are gone/not working in the password manager after the upgrade see this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1146731
How much does Project Silk improves scrolling performance? Can you "feel" it?
Scrolling/motion performance is the only thing that is keeping me away from FF at the moment - Even dev tools are getting amazingly good.
I'm on ff 40 (developer edition), so presumably I've been running project silk for a while now, and for me the scrolling is visually indistinguishable from chrome. The difference is in the inertia: chrome slows to a halt marginally more smoothly, and it does that thing where you can elastically scroll past the end of the page.
The increased smoothness of the inertial model probably indicates that chrome's scrolling is actually better, repaints more closely aligned to vsync or whatever, but like I say there are no actual artifacts, tearing etc. visible on my macbook retina. If you've got a top of the line 120fps gaming monitor its probably more noticeable.
That fancy lcd-testing website probably has some way of measuring it.
For me the big issue is the lack of visual feedback when swiping left and right to go back and forward. In chrome/safari you get a big sliding animation to tell you you're triggering the gesture correctly. In FF you just get an arrow after the gesture has been triggered, when its just annoying visual clutter. This means it still sometimes takes me multiple attempts to hit it, because I don't have that feedback during the gesture to cement the muscle memory.
EDIT: apparently chrome gives you the arrow, ff gives you absolutely nothing.
For what it's worth, I've just updated on OS X and scrolling feels just as janky as ever.
Maybe that's because OS X makes the scroll wheel consider acceleration (move the scroll wheel quickly, you scroll more, move it slowly, you scroll less), unlike Windows/Linux?
Same here. But I'll keep using Firefox because I cant stand what Chrome is doing with my cpu/memory/privacy and I want to keep Safari (the less 'usable' browser) for work related stuff and Firefox for personal ones, on another desktop space.
Two firefox profiles? One for work and one for personal?
Type "man firefox" into your terminal and you will see the relevant options and can set up aliases and shortcuts appropriate for your separated browsing needs.
There are some Firefox add-ons that let you run multiple profiles in separate windows.
Firefox does this out of the box without any addons.
I noticed a huge difference with this site: http://www.2ality.com/2015/02/es6-classes-final.html
In the previous Firefox version scrolling on that site was laggy to the point of being unusuable for some reason.
Definitely an improvement for me. Smooth inertial scrolling on trackpad has been the reason why I still use Safari on OS X.
I can't feel any difference between Chrome and Firefox when scrolling, but http://www.vsynctester.com/ is jankier on Firefox on my old-ish Macbook Air.
I can't wait to write it tonight! This is one missing thing on OSX.
It's OSX only for now.
To those using FF, is there a way to get an "omnibar" similar to Safari?
For example, Safari usually suggests Wikipedia articles or other useful autocompletions. FF only autocompletes from domain names, bookmarks and history, it seems. It does have a separate search input in the toolbar, but even that one doesn't do what Safari does; all the suggested autocompletes are from Google, and additional search engines like Wikipedia or Amazon require that you click on their icon to search.
There's an extension called Omnibar, but it doesn't seem to provide suggestions from other than Google, bookmarks and history.
Firefox's URL bar is literally my favorite Firefox feature. It's quick, it searches my local history much better than Chrome, and it doesn't leak anything to the world.
If I want to search the Internet, I type in the search box.
I really do miss typing part of a domain name (often YouTube), hitting tab, and doing an on site search.
But I'll put up with whatever to support Mozilla. Their work on Firefox and Rust is some of the most important going on.
The preconnect relationship is intriguing; I hadn't been following the adoption of resource hints.
Sidenote: I find it really interesting that the current spec suggests preconnect and its siblings accept a probability attribute estimating how likely connecting to different resources is.[1] Something funny to me about making the directed-graph/state-machine nature of the internet finally show through the markup.
"Drag and drop enabled for nodes in Inspector markup view "
This is going to make me never use Chrome dev tools again. Nice
I can't think of a situation that would make me want to move nodes around from place to place. Where would that be useful?
"Lets see how this document looks when I move this content over there"
A position:absolute div with position:relative parent made sibling of the parent can behave differently.
Chrome dev tools also support node drag-and-drop as well as ctrl-x/c/v in the Elements panel.
Yes, and now that Firefox has this, I do not need to swap to Chrome to use it.
Yey for progress, but one of the most annoying things for me with FF is that if I cmd-t for a new tab, I can't start typing right away for a new search and have that get preserved. There's always some lag and only then do my keys get transcribed. Safari and chrome don't have this problem, and it drives me insane.
That would annoy me too, but I've never noticed it. My main laptop is a Core 2 Duo, so not a speed demon. Have you tried with extensions disabled and/or with a new profile?
Believe so. But either way if its extensions well that sucks because I only have like 2-3 and I want. Extensions shouldn't be written in a way that does that -- chrome and safari don't have this problem and I have about 12 chrome extensions.
If you're wondering what "unicode 8 skin-tone emoji" is about, here you go: http://unicode.org/reports/tr51/#Diversity
Hmmmm, I'm on ff 40.0a2 and they don't render for me: http://emojipedia.org/man-with-dark-brown-skin-tone/
If i ever go to hell i know what my punishment will be - implement unicode
There is a Unicode character PERSON WITH BLOND HAIR, but no corresponding PERSON WITH BLACK HAIR. This is obviously discriminatory. We need new emoji modifiers for: blonde-hair, black-hair, brown-hair, red-hair etc.
That's actually covered in that article:
"As to hair color, dark hair tends to be more neutral, because people of every skin tone can have black (or very dark brown) hair—however, there is no requirement for any particular hair color. One exception is PERSON WITH BLOND HAIR, which needs to have blond hair regardless of skin tone."
You’ll need to have a font installed that supports them, Firefox does not bundle fonts for emoji ;)
What fonts do support them though?
I only recently discovered that Unicode characters can now have colour in them, and frankly, I'm disappointed that we're adding complexity to an already hugely complex topic.
Unicode characters don't have colour in them, much as they do not have a shape either. The Unicode standard does not specify the exact visual representation of any codepoint.
No, fonts can have colour in them. This isn't a new thing, colour fonts have been around for decades. However, they're particularly useful for emoji.
The new combining characters do effectively convey a color even if it is nonspecific and limited to skin tones.
This is bullshit.
The Unicode consortium kinda ran out of useful things to do and has been filling up the address space with whatever comes to mind. Don't worry about it. All the old stuff still works fine.
There are people who write entire sentences in emoji. It is a written language that is understood by speakers of all spoken languages. This just makes the language more expressive.
How so? If you're white, perhaps you see no problem with making everyone's skin white.
But the billions of people who aren't white might have a problem with it.
> How so? If you're white, perhaps you see no problem with making everyone's skin white.
> But the billions of people who aren't white might have a problem with it.
I'm not white, and I have a problem with "skin tone" emoji.
Previously, skin tones for emoji were left up to the font creator. In practice, this meant that they were usually lime green, neon blue, or Simpsons yellow, all of which are cartoonish enough not to be evocative of any particular real-life skintone.
I can't really imagine a situation in which drawing attention to the race of an emoji character is desirable or even acceptable. I'm sure some exist, but they're nowhere near important enough to be included in the actual standard itself.
Beyond that, the skin tones used are incredibly reductive. Human skin tones are not as simple as 6 different shades of brown. (I, for one, cannot match my skin tone to any of the examples on the Unicode website). And if we want to get philosophical, there are a number of ways in which race and culture are encoded (literally) into emoji that are far more subtle, yet more significant, than the color used to render the skin of the faces. In a way, it reminds me of the picture-interpretation tests that they used to administer at Ellis Island to "prove" that certain immigrants were not "fit" for life in the US, though that's perhaps a topic for another day.
> Previously, skin tones for emoji were left up to the font creator. In practice, this meant that they were usually lime green, neon blue, or Simpsons yellow, all of which are cartoonish enough not to be evocative of any particular real-life skintone.
That's not true, IME -- in several of the popular emoji fonts I've seen that don't incorporate specific "skin tone emoji", most emoji for people that aren't expressly silhouettes are white, except a very small number which are black (in both cases, within the range of flesh tones usually associated with those as races, not cartoonish colors.)
EDIT: This is not true of "smiley face" emoji, but of other emoji representing humans or human body parts.
> Beyond that, the skin tones used are incredibly reductive. Human skin tones are not as simple as 6 different shades of brown.
Yes, they are a bit more complicated. But 6 choices that correspond to a widely-used system (Fitzpatrick) is far better than none.
> correspond to a widely-used system (Fitzpatrick)
The fact that a system is widely used when classifying the impact of UV light on melanoma does not imply that it has relevance in another.
> 6 choices is far better than none.
Actually, no, sometimes the "solution" is worse than the problem. It's quite regressive to bake an outdated conception of the color theory of race into a standard that aims to "educate and engage academic and scientific communities, and the general public" (the stated mission of the Unicode Consortium).
As one of the "billions of people who aren't white" that you refer to in your original comment, I find this approach more problematic than the existing status quo (leaving it up to the font creators).
> The fact that a system is widely used when classifying the impact of UV light on melanoma does not imply that it has relevance in another.
You may have a point there. But it is a classification of skin colour as well.
> It's quite regressive to bake an outdated conception of the color theory of race into a standard
Color theory of race? This isn't the Von Luschan chromatic scale, that was used to enforce racial segregation. It's a simple colour selector based on level of melanin.
It's not perfect, sure, but I think it's surely better to allow a choice of skin shades than to make everyone white (the de facto result otherwise). You might object that implementers could make everyone black, say, and that's also true. But either way, you're enforcing a "default" skin colour, and there is no such thing. Different human populations have different skin colours.
> I can't really imagine a situation in which drawing attention to the race of an emoji character is desirable or even acceptable.
Nobody said anything about race, thats your assumption. These emoji are merely presenting different skin tones.
I have never thought of emoji as having any particular skin colour, until this recent trend to make skin colour selectable.
Emoticons and emoji have traditionally been displayed as yellow cirlces with large faces. White emojis have been the exception, not the rule. I have never had a problem with being represented by a character with Jaundice (a medical condition turning your skin yellow).
> I have never thought of emoji as having any particular skin colour, until this recent trend to make skin colour selectable.
If your skin color is already represented you have the privilege of not having to worry about inclusivity of others being represented.
However, I'm not sure this applies to you since I'm not sure what race you are.
> White emojis have been the exception, not the rule.
Not at all true. Most emoji implementations (Japanese mobile providers, Apple) used white faces.
The color was not specified before, so it was up to the font creator. I think yellow was the most common choice. The test page shows all the icons as blue in my browser. I'm not against the new changes, but I think the old version was more popular in Asian countries than anywhere else, and wasn't really pro-white.
Well, Apple made them mostly white. White people holding hands, white people praying, a white family.
Google and Microsoft’s neutral yellow was a lot more neutral there, yes.
> The color was not specified before, so it was up to the font creator. I think yellow was the most common choice.
Nope. Usually white (Apple, Japanese phones).
Thanks for the info. Still, it's hard to believe that Japanese phones would put Caucasian people all over their emoji. Related: "Why Do the Japanese Draw Themselves as White?" https://abagond.wordpress.com/2010/06/16/why-do-the-japanese...
They're not white in the sense of "European". They just have a light skin colour. Japanese skin isn't bright yellow.
A Japanese person draws a simple human face, an American draws a simple human face, both will draw "white" skin.
Way back up in this comment:
How so? If you're white, perhaps you see no problem with making everyone's skin white.
But the billions of people who aren't white might have a problem with it.
I really thought you meant Caucasian. Did you just mean light-skinned?
> I really thought you meant Caucasian. Did you just mean light-skinned?
It would have been better if I said "light-skinned", yes. While East Asians are not "white" in the "racial" sense (ew), their skin is light much like Europeans', and thus when the Japanese created the emoji, they made them have light skin.
Sorry for the confusion.
Emojis are used for communicating emotion, not skin color. If the user want them to be displayed black (or even replace them with cat and dog faces) it should be up to them, it's just a user preference.
Billions of people who aren't white were using and invented emoji before white people even got to them.
> Billions of people who aren't white were using and invented emoji before white people even got to them.
There are not billions of Japanese people and their skin tone is light (though they're not European).
And yet there are still issues on my Sandy Bridge system with display corruption even with the latest Intel drivers.
Also has anyone else noticed that Firefox is no longer keeping the page state when navigating back? For example on Reddit go to the comments section, minimize a few comments then navigate to a link then go back and none of the minimized comments remain minimized, in Firefox prior to 38 things worked correctly.
Yes I have noticed the exact same thing on Reddit lately. My guess it's because they started sending "Cache-Control: no-cache" which prevents Firefox to cache the page for the back button.
Ah yeah that makes sense, I thought it might have been something to do with their recent switch to HTTPS only.
I haven't seen many people mentioning this problem before. I've seen it come up in discussions on the current AMD GPU lines. Hard to say who is to blame, but it's rarely obvious just how many problems there are before buying a card. I got a cheap R7 260x which seems to have trouble with waking up from low power states. Some people even made custom BIOS's to fight the problem.
I don't know how more modern stuff like accelerated transforms, canvas, WebGL or DirectWrite play into that equation. Browsing seems to pull out GPU's from the lowest power modes constantly, which might cause these problems on a wide variety of GPUs.
Can you post a screenshot?
Sure here you go http://i.imgur.com/RNXdLI0.png
Just tried in Nightly and looks like the bug is fixed?
That's possible. It looks like https://bugzilla.mozilla.org/show_bug.cgi?id=1160070
Yes that is exactly my problem! Glad to see it is properly fixed and not "fixed by accident". I will live with h/w acceleration off for a few weeks I guess.
Probably unfair of me, but when browsers have a new .0 release, my brain automatically thinks "Oh good, new security bugs."
firefox is on a 6-week release schedule, and has been for a while. They increment a by whole number each time, but the for both chrome and FF they shouldn't really be thought of as .0 releases. It's a fairly minor, incremental change.
Windows XP never stopped having bugs, and who knows how many patches they'd applied to it.
So, they finally fixed Logjam, 1 month and a half after publication.
Chrome still hasn't fixed it. Color me unimpressed.
It's fixed in the dev channel, it just hasn't propagated to stable or beta yet.
Since Chromium is open source, you can contribute to the project. I'm sure if you send a quality patch to the Chromium dev team to fix Logjam, they'd be willing to review it.
Did you try to contribute to Chromium and Firefox to speed up fixing the Logjam issue ?
>Did you try to contribute to Chromium and Firefox to speed up fixing the Logjam issue?
No. The issue isn't that it's (so) hard to fix; the fix in 39 has been out for a while, they just didn't want to release it for the stable release, which means few people got it. (In fact, some distros apparently fixed their versions earlier [1]).
On Firefox, you could manually fix it in 2 minutes [2]
I'm not familiar with the codebases, so it would take me longer to make a patch, but it really should not take 2 months to release to stable a fix that affected 8.4% [3] of popular websites, especially for a company like Google.
The tinfoil hat in me says certain things about this, considering that logjam was likely known by the NSA, but then again I can't prove anything.
I'm a bit surprised there hasn't been more talk about this, actually. A major security hole going unfixed for months after public disclosure should have had more chatter.
[1] https://news.ycombinator.com/item?id=9702061 [2] http://techdows.com/2015/05/how-to-make-firefox-browser-safe... [3] https://weakdh.org/
Why should one provide a patch for Google's browser. Google are rich they can do it themselves? The day that Chrome is a verified build of Chromium with all the Google centric stuff as optional add ons is the day sending Chromium patches makes sense.