1.48 MB, application/x-7z-compressed
User Agent: Mozilla/5.0 (Windows NT 6.0; rv:21.0) Gecko/20100101 Firefox/21.0 (Beta/Release) Build ID: 20130511120803 Steps to reproduce: 1. Go to http://www.sclegacy.com (must be the first time after starting Firefox -- may need to be the first time starting Firefox after starting the computer -- not sure yet). 2. Attempt to do stuff (anything) while the page is loading. Actual results: The entire operating system EXCEPT for the mouse cursor freezes for slightly under 30 seconds (all keyboard response disabled, and even the Caps Lock and Num Lock lights cease to respond). If you click on enough things (apparently anything) during this freeze, the system beeps and freezes the mouse cursor as well. At least most of the time, the system eventually recovers. Note that if you go back to the page (or reload it) after this has happened, the problem does not occur. Need to test: Does step #1 above have to be the first time after starting Firefox any time, or the first time after starting Firefox the first time after booting the computer (or logging in, or something)? Expected results: The system and Firefox should not freeze. Initially, I was inclined to blame this on Windows Vista (SP2, 32 bit), especially given that Firefox 12 on Windows 2000 SP3 (can't run Firefox >12 on Windows 2000) freezes itself for a while but does not freeze the whole system; HOWEVER, this started happening somewhere in the early teens of Firefox version, and DOESN'T happen on other web browsers on the Windows Vista computer: Google Chrome latest version until a few days ago (Version 26.0.1410.64 m) and Safari latest version (5.1.7) on Windows Vista: Page takes a LONG time to load, but doesn't freeze browser (let alone whole system). Internet Explorer 9 (latest patch as of a few days ago) on Windows Vista: Page loads quickly, and no freeze. Need to test: Latest version of Firefox on a Windows XP computer (work computer, though, so have to wait until I'm officially off the clock and DON'T have to rush to catch a bus before I can test that site there :-P).
One To-Do (above) down (and another one while I'm at it): Apparently the bug only occurs when loading http://www.sclegacy.com/ in Firefox the first time after starting the system, but apparently it doesn't matter if Firefox has loaded other pages beforehand or even been quit and restarted. In addition, it occurs even when starting Firefox with Add-Ons Disabled (Safe Mode). On the thought that maybe any web browser does this if it is first to load this page after starting the system, I tried Internet Explorer 9 again before starting any other web browser, but while it freezes itself for a few seconds in this case, it doesn't freeze the whole system (behavior similar to Firefox 12 on Windows 2000). It also doesn't prevent Firefox from thereafter freezing the whole system temporarily while loading the page. I haven't yet tried every combination of system restart, loading this page with a non-Firefox web browser, and then loading it with Firefox, but so far it seems that only having Firefox go to this page seems to prevent a future freeze (and before going to this page for the first time, it doesn't seem to matter what other pages Firefox has gone to, or if it has been closed and restarted before going to this page for the first time). Have not yet distinguished between behavior after a complete power cycle compared to a warm restart. One other bit of information: When this freeze occurs, at least after also freezing the mouse cursor the hard drive light is on solid or nearly solid until the system recovers (didn't think to check the hard drive light while the mouse cursor hadn't yet frozen). Speculation: Given that when loading pages with plugins I often see leftover partial images from previously loaded plugins, and that http://www.selegacy.com loads plugins from at least YouTube and probably also twitch.tv, I wonder if the problem is consumption of all available physical memory forcing some kind of massive garbage collect or pagefile reallocation of plugin memory, and this garbage collect or pagefile reallocation completely takes over the whole system until it is done. Not sure why this would only occur the first time loading the page after starting the system, though, or why only this page (so far) would exhibit the problem (normal YouTube pages do not do this, even when Adobe Flash Player crashes, even though in earlier versions of Firefox an Adobe Flash Player crash used to be able to take out Firefox). Note: This computer has been tested with MEMTEST86 and passed, but I recognize that this isn't a guarantee that the memory does not have problems (maybe only Firefox hits a certain bad spot that MEMTEST86 can't detect?).
Haven't yet had a chance to test it on a Windows XP machine, but I did determine that on rare occasions pages other than http://www.sclegacy.com/ can elicits the bug -- for instance, http://www.facebook.com/ -- but the former is the only one (so far) that consistently elicits this bug (provided that the conditions in the original post are met).
Tried to test after hours on a Windows XP machine at work, but the institutional firewall blocks the site entirely -- sorry.
In the last 3(?) weeks, Yahoo changed something so that going into Yahoo web mail now consistently elicits this bug (and still does it in Firefox 24.0). Next step: Test Firefox on Yahoo web mail on a Windows XP and Windows 7 computer at work after hours (our institutional firewall doesn't block Yahoo web mail, last time I checked).
Finally got the chance to try Yahoo mail on 2 computers at work: Windows XP Professional SP3 and Windows 7 Professional SP1. No freeze (even to itself) on these, so this problem must be something specific to the interaction of Firefox with Windows Vista (unless Yahoo did a dirty trick and changed Yahoo web mail again today :-) ).
Able to reproduce on the following specs: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0 Might be related to Bug 1238275
Component: Untriaged → Layout
Product: Firefox → Core
> Able to reproduce on the following specs: Are you able to do a profile? Which actual steps to reproduce are you using?
Hi Boris, I refreshed Firefox Nightly in order to create a new profile and was able to recreate the bug. Steps to Reproduce: 1. Open Firefox/Nightly 2. Visit http://www.sclegacy.com 3. Scroll or click any element on the screen.
No, I mean a performance profile, e.g. using the steps at https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Profiling_with_the_Built-in_Profiler
Created attachment 8707039 [details] Performance Profile File - Windows Vista Bug 874756 Hi Boris, Attached is what I think is the performance profile. Please confirm this is whether or not you are asking for. An addendum to the Steps to Reproduce above: It only freezes on the first instance after the OS is booted. It can't be replicated if Firefox is simply closed or the profile is refreshed.
Thanks, that's exactly what I was looking for. The profile shows a bunch of time (7 seconds or so) under the NtGdiGetGlyphOutline function, called from _cairo_win32_scaled_font_init_glyph_metrics and then a callstack back up into text drawing. This may be the "something just forced us to look through all the glyphs of all the fonts" thing that can happen if we run into a particularly weird char soon after starting (before we have had a chance to load the glyph data in the background)...
Component: Layout → Layout: Text
From the comments, it does sound like this could be related to touching lots of fonts that GDI or Gecko hasn't yet had occasion to load. I don't see offhand why we'd need to exercise ...init_glyph_metrics so heavily, though, even the cmap-based font fallback codepath should only need to load cmap tables, not actual glyph data for all the fonts. But perhaps we're not actually making masses of calls to it; maybe a single call from the app can end up causing GDI to spend ages loading font data internally. John has done more work on the font-loading and fallback code lately than I have...
Flags: needinfo?(jfkthame) → needinfo?(jdaggett)
I suspect this is an old DirectWrite bug under Windows Vista. Grover, could you copy your 'about:support' info into this bug? In particular, I need to know whether you're using DirectWrite and, if so, which version.
Flags: needinfo?(jdaggett) → needinfo?(gwimberly)
You need to log in before you can comment on or make changes to this bug.