I am measuring the performance from a website. When looking at the firefox-developer-tools, I noticed a weird behavior. There is a specific JS file which the transferred size is 2,831.54 KB, but the actual size is 1280kb.
According to Mozilla, the Transferred size should be smaller or equals to Size:
Transferred (new in Firefox 38): the number of bytes that were
actually transferred to load the resource. This will be less than Size
if the resource was compressed.
Size: the size of the resource, after
any decompression.
Firefox Developer Edition version: 41.0a2 (2015-07-19)
What could have caused this behavior?
As stated in the most upvoted comment on the question:
This appears to be a rare bug in Firefox that has been fixed in Firefox 52:
FWIW this bug has been fixed and the fix will appear in Firefox 52.
– Tom Tromey Feb 14 '17 at 14:59
Related
I recently bought a new 2019 iMac, 27-inch screen with the Retina 5K display. It was meant to replace my older late-2013 model which has been my workhorse for a long time.
Shortly after getting up and running with Chrome, I noticed that certain headings on websites were bolder than I remembered, and was able to figure out that it was happening with websites which used a variation of the system font stack. Specifically, if font-family was set to BlinkMacSystemFont or system-ui, headings were often no longer rendered with the correct font weight. Everything appears as if font weight was set to normal.
What's weirder is that through some fiddling around in dev tools (Codepen link) I've figured out that this only happens with font sizes at or above 20px, so there's some kind of size dependency which affects the issue. It also seems to have something to do with font smoothing, as font-weight starts working again if I set -webkit-font-smoothing: none;, but then it looks absolutely terrible. See below for a screenshot of what I mean.
I'm completely baffled by this. I've tried installing San Francisco from Apple Developer resources. I've gone to Font Book -> File -> Restore Standard Fonts, which didn't work. I've also tried both checking and unchecking 'Use font smoothing when available' in Settings -> General.
If I open up Chrome's dev tools and go to Computer -> Rendered Fonts, it says .SF NS, which I assume means it's finding San Francisco just fine, but apparently stops working above 20px.
This only happens on Chrome, and only happens on my newer iMac. My older 27-inch iMac doesn't have this display problem, or any of my other Apple devices with Catalina and Chrome. So maybe it has something to do with the 5k display? Unclear.
My Chrome version is current, as of this writing it's Version 81.0.4044.113.
Edit:
Some additional digging:
If I manually specify "SF Pro Text" or "SF Pro Display" for the font-family, it renders correctly with the right weights.
This Chromium bug report seems very relevant, which links out to a section of Apple's developer guidelines which would explain why it's changing at exactly 20px - because that's when the system tries to use SF Pro Display instead of SF Pro Text. Maybe that indicates an issue with the internally installed versions of these fonts:
Use SF Pro Text for text 19 points or smaller, and SF Pro Display for text 20 points or larger. When you use San Francisco for text in standard controls like buttons and labels, macOS automatically applies the most appropriate variant based on the point size and the user’s accessibility settings.
A related chromium bug report which describes the problem as related to kerning / tracking. It's closed, and makes no mention of font weight, but seems like the root cause might be the same.
Found the correct chromium bug. As of this writing still open but hopefully will be fixed soon: Issue 1057654
What is the min version of each browser (IE, Chrome and Firefox) for LESS running on client-side?
According to http://blog.montylounge.com/2011/07/31/one-thing-about-lessjs/ it's IE6+, although they don't specify which versions of Chrome and Firefox are supported. I would assume far enough back that it shouldn't cause you any problems.
As the fact there are some historical reason and bugs in some browsers (desktop and mobile), not all of them support rfc5987, rfc2231, rfc6266 and others.
I'd like to detect it and do some workaround. How can I do the detection especially there are unknown number of mobile browsers?
Test Cases for HTTP Content-Disposition header field (RFC 6266) and the Encodings defined in RFCs 2047, 2231 and 5987
Don't; the mess Content-Disposition is in partly is caused by servers attempting to do user agent detection and getting it wrong.
For desktop browsers the problem is well-understood; either special case IE<9 and Safari, or send them both filename and filename* and let them fallback to ASCII.
For mobile browsers I would encourage to do the same: Firefox supports filename*, Android's browser (when I last checked) didn't support non-ASCII at all, and Safari didn't "save as" anyway.
I'm not sure if this has anything to do with the recent Safari update, but I'm beginning to notice this a lot. There is a drastic difference in the way each browser is rendering fonts.
for instance, I took screenshots of what I am seeing here on stackoverflow...
http://twitpic.com/q43eh
I have verified that this is a trend via my co-workers machines.
has anyone noticed this or have any thoughts on non-hack solutions?
Font rendering isn't specified anywhere in the standards and therefore may (and will) vary between browsers and platforms.
In particular, Safari on Windows renders fonts like OS X does which tends to look weird to Windows users as Windows has quite a different take on how to render fonts than OS X.
You can definitely notice this, especially if you use Expression Web SuperPreview. This is just a general problem of the web, just like folks can hit Ctrl-+ and make your text bigger. Try not to use many absolute coordinates in CSS and the layout engine will ensure it's still readable
I first noticed this in OSX in October 2010. It is especially noticeable with Helvetica Neue. I suspect that an OSX update broke font anti-aliasing in font sizes above 12 pixels. I've posted an Apple Support message here.
I've got a website that I've just uploaded onto the interwebs, and it's displaying differently using Firefox 3.0.1 on Ubuntu and WinXP.
Two things I've noticed on Ubuntu:
The favicon is missing
The background color isn't displaying (it's set in the stylesheet)
What have I done wrong? The CSS file is being fetched under Ubuntu, so why isn't it applying all of the stylesheet, just the bits it likes? And why isn't the favicon displaying? Are they the same problem?
The answer on the background color: invalid HTML. But I'd love for someone to explain why it works under Windows and not Ubuntu.
The answer on favicon: previously, there was no favicon. The browser cached the lack of favicon. Clear the Firefox cache, and all is well.
I would first suggesting getting you html and css code validated. If there are any errors in your markup, these can cause errors in the rendering.
CSS Validator
HTML Validator
I've also run into differences between FF3 on WinXP and FF3 on OS X (mostly with CSS positioning). The CSS and HTML both validated properly, but I was never able to figure out why there was this difference. I would think that the rendering engine would be the same, but apparently there are at least a few subtle differences.
I agree.. there are subtle differences between the two operating systems. Part of this is just font sizes and how line height and letter spacing is determined. So much of page flow is based on these whitespace elements interact with other page elements.
i believe this is a font issue and a browser / OS issue.
we know that different firefox versions are dependent on the OS - there are some firefox extensions available for Linux, some firefox extensions for windows are available.
it's the font I guess.
Try to download mtts core fonts (microsoft true type ) which includes all the windows fonts so that firefox can display the fonts you specified in the css.
also you could check that you use fonts which are available on both platforms. Otherwise, I suggest rechecking and revalidating your code.
The other issue could be the screen resolution. It might be okay in windows with your high resolution but not with the low resolution ubuntu version.
Almost too obvious to say, but are they both "Firefox 3.01"? One isn't, for instance, Firefox 3.01 revision 3 update 6 service pack 9 and the other, well, you get the picture.
Even if they were both the very latest Firefox for that platform, doesn't mean they're exactly the same thing.
To see what's different, enter about:config in the address bar in Firefox in both Linux and Windows, press Enter, and compare the output
Ubuntu (I believe) apply their own patches to Firefox, so maybe this cause. Having said that, I thought that the patches were only for minor, GUI-type changes.