Closed Bug 769398 Opened 13 years ago Closed 11 years ago

Mac Firefox drops frames when playing Netflix on OS X 10.7.4 in (Silverlight) fullscreen mode

Categories

(Core Graveyard :: Plug-ins, defect, P3)

Product:
Core Graveyard
Component:
Plug-ins
Version:
2.0 Branch
Platform:
x86
macOS
Type:
defect

Tracking

(firefox13-, firefox14-, firefox15-)

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
firefox13 - ---
firefox14 - ---
firefox15 - ---

People

(Reporter: jbecerra, Unassigned)

References

Details

(Keywords: regression)

Attachments

(2 files)

Fx13 vs Fx3.6 graph
235.83 KB, application/pdf
Details
Screen shot of frame rate drop
100.25 KB, image/png
Details
On a Macbook Air 13" running Mac OS X 10.7.4 with 1.7ghz Core i5 and Intel HD Gfx 3000 384MB. Matthew at Netflix reports that Firefox 13 has a high rate of dropped frames when playing Netflix: "When playback performance is poor, i.e. when many frames are being dropped, the Netflix player adapts and lowers the video bitrate. As you can see in the graphs, Firefox 13 drops frames at the rate of ~6.8 per second (it’s unwatchable), which causes the player to shift down from HD, to SD, and finally to our very lowest bitrate; but even that lowest bitrate is unplayable. In contrast, Firefox 3.6 can sustain HD at a much lower rate of dropped frames." Attached is the PDF file with the graphs showing the problem.
Attached file Fx13 vs Fx3.6 graph —
NetFlix uses Silverlight, right? I assume this is with the latest version? It'd be interesting to get a comparison of previous Firefox releases (12, 11, 10, etc).
Status: NEW → UNCONFIRMED
Ever confirmed: false
We need to know which version of 3.6 this was tested on (OOP or not) as well as which Silverlight version. I'm waiting to hear from Matthew.
From Matthew: Silverlight version is 5.1.10411 Firefox was 3.6.28
Keywords: qawanted
Juan, can your team help us find the offending change? That would likely go a long way to getting this properly assigned.
Keywords: regressionwindow-wanted
We're working on it. Does any one know of a frame rate monitor add-on we can use to get numbers?
Netflix has a few handy keyboard shortcuts that display this kind of information, and I'm using those to find a regression range. (Search the web for "Netflix Movie Player Keyboard Shortcuts")
Status: UNCONFIRMED → NEW
Ever confirmed: true
tracking-firefox13: --- → ?
tracking-firefox14: --- → ?
This is what I have found so far. Macbook Air, 10.7.4, Silverlight 5.1.10411.0, Fx4 - 13: Low rate of dropped frames in normal mode. High rate of dropped frames in fullscreen mode. Chrome works fine. Low rate of dropped frames in normal and fullscreen mode. Macbook Air, 10.7.4, Silverlight 5.1.10411.0, Fx3.6.28: Low rate of dropped frames in both normal and fullscreen mode. Older Mac Mini, 10.6.8, Silverlight 5.1.10411.0, Fx3.6.28, Fx13: Low rate of dropped frames in normal and fullscreen mode (about 5). Newer Mac Mini, 10.7.3, Silverlight 5.1.10411.0, Fx13: Low rate of dropped frames in normal and fullscreen mode. So it looks like there are no dropped frames in normal mode, across the board, but there are definitely a few frames dropped every second in fullscreen mode in Fx4 and up. In my machine using Mac OS X 10.7.4 the rate is very high and immediately noticeable. I'll next look for the builds before and after landing some of the plugin drawing code that changed between 3.6.x and 4.0, but the fact that there are differences between 10.7.4 and the other Mac OS X versions could point to something else. During my testing I left the machines play for a few minutes while I noted the frame rate and dropped frames as displayed by the A/V diagnostics using Shift-Ctrl-Option-D.
(In reply to juan becerra [:juanb] from comment #8) > So it looks like there are no dropped frames in normal mode, across the > board, but there are definitely a few frames dropped every second in > fullscreen mode in Fx4 and up. In my machine using Mac OS X 10.7.4 the rate > is very high and immediately noticeable. From what you list above it looks to me like only 10.7.4 is experiencing this issue in fullscreen mode. > > I'll next look for the builds before and after landing some of the plugin > drawing code that changed between 3.6.x and 4.0, but the fact that there are > differences between 10.7.4 and the other Mac OS X versions could point to > something else. > Great, I'll set tracking for 14 (with such a small user base for 13 Mac OS X 10.7.4 I don't think we need to track for 13 at this point in the cycle) and we'll hope to hear back with a regression range to investigate more.
tracking-firefox13: ? → -
tracking-firefox14: ? → +
Steven - would you mind taking a look at this some time this week? Although it's not a FF14 regression, 10.7.4 was released recently and may very well be the culprit. We feel this is a higher priority than bug 740923 given Netflix's popularity, although neither is really a blocker for FF14's release.
Assignee: nobody → smichaud
I don't have a Netflix streaming account, so I won't be able to work on this bug if one is required. Also, someone needs to give a *much* better (more precise and detailed) description of how, exactly, to test for this bug.
Steven: I have a test account from Netflix and would be happy to send you the login details. I can also engage the folks at Netflix and have them clarify any details they have to test this bug. (In reply to Steven Michaud from comment #11) > I don't have a Netflix streaming account, so I won't be able to work on this > bug if one is required. > > Also, someone needs to give a *much* better (more precise and detailed) > description of how, exactly, to test for this bug.
Marcia, please do send me the login details for that test account. Please also do bring in people from Netflix.
Steven, once you get the Netflix account and are able to login: 1. Play any video. 2. Click the fullscreen mode control in the video. You will notice playback stutter in fullscreen mode. 3. Go back to normal mode by pressing the Esc key. 4. Press Shift-Ctrl-Option-D while the video is playing. It should show some diagnostics while the video plays including an entry for frames per second and droppred frames per second. 5. Monitor these numbers for a minute or so. 6. Go to fullscreen mode again and compare the numbers. You should see a big difference in dropped frames reported by the diagnostics that appear, which are noticeable when you play the video.
I've now had a chance to spend some time on this. What I found indicates this is at least partly a Silverlight bug. Also, this bug is *not* a serious UI bug -- at least not in my tests. The worst rate of frame-dropping that I saw was one frame every 2-3 seconds (though sometimes 4-5 frames got dropped at once shortly after the transition to fullscreen mode). Testing on OS X 10.6.8 and 10.7.4, I only saw somewhat bad frame-dropping (on average one frame every 2-3 seconds) on OS X 10.7.4, in fullscreen mode, running Silverlight out-of-process, and using the two versions of Silverlight 5 whose installers I have copies of (5.1.10411.0 and 5.0.61118.0). I did not see this problem, even on OS X 10.7.4, running Silverlight 4.1.10329.0. I also didn't see it running Silverlight 5 in process (which I think explains the difference from FF 3.6.28, which always runs plugins in process). Interestingly, the problem is quite a bit worse with FF 4.0.1 (running Silverlight 5 out-of-process on OS X 10.7.4) than it is with FF 13.0.1. That probably reflects the optimization we've since made in our OOPP code. Note that Silverlight doesn't want to let you uninstall it. And doing so on OS X 10.7 and up is more tricky than doing so on OS X 10.6 and below. On OS X 10.6 and below, you just need to delete the following: /Library/Internet Plug-Ins/Silverlight.plugin /Library/Receipts/Silverlight*.pkg But the Silverlight*.pkg file doesn't exist on OS X 10.7 and above. There you need to do the following instead: sudo pkgutil --forget com.microsoft.SilverlightInstaller
(Following up comment #15) For the record, I tested on a ~1 year old MacBook Pro with 8GB of RAM.
Note that it's only practical to run Silverlight in-process in current release builds (FF 13.0.1 and below). Do it by running FF in 32-bit mode. Current release builds are now made on OS X 10.6. But all other builds are (I think) made on OS X 10.7, which means that they're effected by bug 753248. Bug 753248 and bug 759364 are now fixed on the trunk and all branches. But even after these fixes, running Silverlight in process makes you crash on all branches but the release branch.
WRT to this bug not being seen with Silverlight 4: It's possible that Silverlight 5 uses a different kind of NPAPI support in FF than Silverlight 4. If so, then this bug might not be a Silverlight bug after all. It'll take more investigation to figure that out, though. Hopefully I'll be able to find some time for it next week.
Summary: Firefox 13 on the Mac has a high rate of dropped frames when playing Netflix → Mac Firefox drops frames when playing Netflix on OS X 10.7.4 in (Silverlight) fullscreen mode
As best I can tell, Silverlight 4 uses the NPAPI no differently when running in Firefox than does Silverlight 5: Both set the drawing model to CoreGraphics and the event model to Cocoa. So it looks like this bug is largely a Silverlight bug, or perhaps a combination of Silverlight bugs and OS bugs. I'm not aware of any ways in which FF implements the CoreGraphics drawing model or the Cocoa event model differently on OS X 10.7 than on OS X 10.6. Are you, Benoit?
I also don't know why this bug happens only in (Silverlight's) fullscreen mode.
When a plugin enters full screen it brings up it's own windows and drives the drawing itself. Ideally the plugin shouldn't be trying to paint behind the full screen. The only thing I can think of is that we share the event loop but I doubt that's the problem. I've been using Silverlight via Netflix recently and haven't noticed any problem on 10.7.3 but I have a high spec MBP.
(In reply to Steven Michaud from comment #19) > So it looks like this bug is largely a Silverlight bug, or perhaps a > combination of Silverlight bugs and OS bugs. Given that, untracking for releases.
tracking-firefox14: + → -
tracking-firefox15: + → -
I want to confirm that I've seen this exact behavior since 10.7.4, and am still experiencing it on 10.8 and Firefox 16. I have a 2010 MacBook Pro with 4gb of ram and a nvidia 7600gt. Chrome and Safari also occasionally show this behavior, but extremely intermittently compared to Firefox. I've attempted to manually set the buffer/stream rate, with no effect (hold option shift and left click, and choose stream manager). If I do the same in chrome or safari when this occurs, playback becomes smooth. This leads me to believe that the problem could even be in the Netflix player's variable bitrate detection/streaming code (since manually setting it resolves the issue). Of course, this opinion Is unfounded and I lack any detailed knowledge of any of the required internals to diagnose this issue. If anyone knows how to get more information out of silverlight/Netflix player, or some sort of log (or something equally scientific) please let me know, as I can reproduce this everytime. At this point, it sounds like it's a combination of a silverlight bug as well as some sort of issue with FF OOPPs that causes it to manifest more frequently than the other browsers.
Depends on: 782672
I was also experiencing significant frame drop under Silverlight 5 with Mountain Lion 10.8 running Firefox 15.0.1. At some point past I recall setting FF to specifically open in 32 bit mode to get it to play nice with Silverlight 4. At present, this setting appeared to be the cause of my video stuttering. After unchecking "open in 32 bit" in the finder "get info" window for FF, I am no longer dropping frames.
Was there any solution to this problem? Experiencing exactly the same problem with a silverlight player based on the SMF framework, and smooth media client from Microsoft. It seems to work fine for FF 3.6, and seems to be dropping frames on FF 16.0.2 and OSX 10.7.5.
I don't know if there's been any solution in the code; I know that I'm still experiencing it. Firefox is NOT opening in 32-bit mode. Silverlight 5.1.10411.0 FF 16.0.2 Mac OSX 10.8.2
I'm having issues when I'm playing Netflix in full screen mode as well. The video content freezes. The sound continues to play but the video doesn't move. It won't allow me to exit out of full screen mode once it's stuck. I've had to reboot my machine once I experience the issue. It won't allow me to exit or close Firefox. Machine is a Macbook Air running 10.8.2. Running Firefox 16.0. Silver light 5.1.
What value is under 'GPU Accelerated Windows' in the about:support page?
Not sure if that question was for me... but the answer is 1/1 OpenGL.
(In reply to Benoit Girard (:BenWa) from comment #28) > What value is under 'GPU Accelerated Windows' in the about:support page? Same as Winston's here: 1/1 OpenGL.
Confirmed it's still an issue on Firefox 18.0, OSX 10.8.2, Silverlight 5.1.10411.0
(In reply to rimbosity from comment #31) > Confirmed it's still an issue on Firefox 18.0, OSX 10.8.2, Silverlight > 5.1.10411.0 Can you try using the mozregression tool to find a regression window? We've made no progress on this bug and are unlikely too until someone finds the change that broke this. http://mozilla.github.com/mozregression/
Keywords: qawanted
I'm having some difficulty finding a "good" nightly. I HAVE confirmed that the 3.6.28 Release is fine and that the 4.0 Release is not, as Juan did above. (The difference is very obvious; fullscreen is essentially unwatchable on 4.0 and above.) What's a good nightly that is in 3.6.28's ancestors?
Looks like 2009-06-01 was in the "Firefox 3.6 is trunk" time-range, based on https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2009/06/2009-06-01-03-mozilla-central/ so you could try that date or a date around there.
That's what I've been doing, and they always were crashing. Then, I had the brilliant idea to actually read the error message it was giving me. Oh, hey, look, there's part of my problem: I don't have CHUD installed, and the Minefield.app wants it. LOL: 10.8 doesn't recognize CHUD's developer, which is Apple. OK, I've been able to get the Minefields to work at that point, except that Netflix appears not to like them. It likes 2011-01-01 nightly, but doesn't like 2010-06-01. I'm manually bisecting them for the moment. (2011-01-01 is showing the issue.) I wonder if it's keying off the User-Agent string; what magic incantation could I chant to alter that?
FOUND a good one! And it looks like it's somewhere between 2010-09-01 and 2011-01-01. I'll run mozregression now with those values and let you know what happens.
2010-09-01 runs flawlessly in a window and in fullscreen. Last "good" nightly: 2010-11-01 First bad nightly: 2010-11-02 Sometime between those two, it went bad, but there's a catch. For 2010-11-01 to work, I had to continuously click on the screen while running in the Firefox window in order for the screen to refresh. If I do this a few dozen times, I eventually get the Netflix control panel to show, and can click on the "Fullscreen" button there. When it goes Fullscreen, it runs flawlessly. 2010-11-02 fixes the "click in the window to refresh in windowed" mode, but BREAKS fullscreen. I'm going to run this and see when that "click to run in window" bug occurred.
Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f4ea6992e1c6&tochange=45d6a73ef138 Possible regressive changeset: http://hg.mozilla.org/mozilla-central/rev/f50d5573200f Josh Aas — Bug 594635: Fixes for OOP Core Animation NPAPI, fixes Quicktime plugin on Mac OS X. r=benwa a=josh/johnath
(In reply to rimbosity from comment #37) > For 2010-11-01 to work, I had to continuously click on the screen while > running in the Firefox window in order for the screen to refresh. If I do > this a few dozen times, I eventually get the Netflix control panel to show, > and can click on the "Fullscreen" button there. I wouldn't put too much emphasis on this behaviour. These are really old builds and I would not expect present-day web technology to work flawlessly on 2 year old browser technology. Great work finding this regression range though!
Keywords: regressionwindow-wanted → regression
Version: 13 Branch → 2.0 Branch
OK, here's the complete timeline as far as I can see: 2010-09-26: This is the last nightly build where everything works flawlessly. 2010-09-27: Netflix doesn't work at all, I see a "Thanks for installing; quit your browser to restart and watch bla bla" 2010-09-28: This is where we see the behavior where you have to click inside the browser window to get the plugin to refresh, but fullscreen works perfectly 2010-11-02: No longer have to click the window to refresh, but fullscreen drops frames like crazy. So it looks like someone tried something between the 26th and 28th that introduced a bug, which was then fixed on 11/2; however, that fix introduced this bug.
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #39) > (In reply to rimbosity from comment #37) > > For 2010-11-01 to work, I had to continuously click on the screen while > > running in the Firefox window in order for the screen to refresh. If I do > > this a few dozen times, I eventually get the Netflix control panel to show, > > and can click on the "Fullscreen" button there. > > I wouldn't put too much emphasis on this behaviour. These are really old > builds and I would not expect present-day web technology to work flawlessly > on 2 year old browser technology. Au contraire! It works flawlessly up 'til 9/26, per above. I bet some change(s) made in that time-frame will be informative for tracking down this issue.
(In reply to rimbosity from comment #41) > Au contraire! It works flawlessly up 'til 9/26, per above. I bet some > change(s) made in that time-frame will be informative for tracking down this > issue. Perhaps, but I still think investigating Bug 594635 is the best next step.
Yeah, Bug 594635 is what I'm seeing between 09-28 and 11-01. Which is weird, because it was reported on 09-08. mozregression downloaded 09-01, 09-16, etc and nothing showed that until 9/28. Weirdness. Holes in the space-time continuum?
Still seeing this in FF 19.0, OS X 10.8.2, Silverlight 5.1.10411.0. Anything else I can do to assist with this?
(In reply to rimbosity from comment #44) > Still seeing this in FF 19.0, OS X 10.8.2, Silverlight 5.1.10411.0. > > Anything else I can do to assist with this? Not really. The next step is for a developer to look into whether bug 594635 introduced this regression and for someone to write a patch to fix it. Until these steps are taken this bug will continue to exist.
What I found in comment #15 indicates that this is not a particularly urgent bug. Given that, and the fact that all my time is usually taken up with much more urgent bugs, it's highly unlikely that I'll be able to spend time on this anytime soon.
Assignee: smichaud → nobody
Priority: -- → P3
(In reply to Steven Michaud from comment #46) > What I found in comment #15 indicates that this is not a particularly urgent > bug. Yeah, what you described in comment #15 is not at all what I'm seeing happen. Netflix is unwatchable on Firefox, where everything is reduced to the framerate of poorly-done stop-motion animation. That's fine if all you watch is Wallace & Gromit and don't mind Nick Park's great work reduced to a shadow of its former self; it's not at all good the minute you try to watch something live-action. I did the diagnostics thing (shift-ctrl-alt-D) and I'm seeing an average of 12 dropped frames per second, and never fewer than 8 or 9 per second, and often in the high teens.
So there's one REALLY odd thing about this. I captured this using OS X's built-in screen-capture utility (cmd-shift-4, hitting space to get the full screen). When I hovered the full-screen shot camera icon over the window, the framerate drop went to 0. Of course, since the screen was muddled by the highlight, it's still unwatchable; however, it's interesting that by adding an overlay, the problem ceases.
To those who see this bug worse (and more clearly) than I do: Please test with different versions of Silverlight. I suspect you'll find significantly different results with different versions. If you do, please report them here and to Microsoft.
Where would we get different versions of Silverlight to test with? From some quick Googling, I can only find the latest version of silverlight (plus SDKs for older versions). (I've been seeing this bug very clearly for months (since first getting Netflix) on my home mac mini w/ OS X 10.7.5, silverlight 5.1.10411.0, & up-to-date Aurora).
Download the "Microsoft Silverlight Release History.htm" file from http://www.microsoft.com/en-us/download/details.aspx?id=12121. Then save it to your desktop and double-click on it. (I've no idea why Microsoft added the extra step.)
(In reply to Steven Michaud from comment #49) > To those who see this bug worse (and more clearly) than I do: > > Please test with different versions of Silverlight. I suspect you'll find > significantly different results with different versions. If you do, please > report them here and to Microsoft. I know you're busy and haven't had time to read the thread, but we've already produced a regression window for this; the behavior has been the same for many different versions of Silverlight, and changes only when you change Firefox versions. (The same version of Silverlight also has no problems in any other browser.) Forgive me for being blunt: this has all the appearance of a coder getting in a hurry and attempting to address bug 594635 with a hack workaround that hasn't actually fixed the problem, instead of doing the "proper fix" by addressing bug 608491. (Oddly enough, I'm only getting that impression because that's what BenWa said in bug 608491.) I suspect that if the "quick fix" for 594635 is simply backed out and 608491 is fixed instead, then both the original Quicktime issue AND this one will be addressed. We've been able to show that the problem here did not exist before the changes for bug 594635 were checked in and did show up immediately afterweards, so ashughes is correct that investigating what was done for that issue is the likely next step. Now if I were Mozilla's QA engineer, what I would do is reopen bug 594635, then mark 769398 as a duplicate of 594635 and close it.
Also note what I said in comment #15 about uninstalling Silverlight. You need to do this before installing an older version over a new version. And finally note what tests I've already performed in comment #15. Do them again, and let us know if you get different results.
(In reply to comment #52) I *have* read the whole thread -- several times and very carefully. But I can't really reproduce the bug (at least as cleanly as other people seem to see it). So there's not much point in me trying to work on it.
(In reply to Steven Michaud from comment #54) > (In reply to comment #52) > > But I > can't really reproduce the bug (at least as cleanly as other people seem to > see it). So there's not much point in me trying to work on it. That's a fair cop. It's just that right now, all signs point to this being a Firefox bug. (Incidentally, Netflix won't even allow Silverlight 4 now, and Firefox really doesn't like it running Firefox had automatically disabled it, and I had to enable it. Uninstalling and reinstalling 5, per your instructions, had no effect.)
It's been a while since I tested, and things may have gotten worse. Sometime in the next week or two I'll re-run my tests, on several different machines (and on different versions of OS X). I may find that I can now reproduce this bug, too. Rimbosity, your work shows that Firefox plays a part in the problem. But my tests with Silverlight 4 (which Netflix still allowed when I did them) show that Silverlight also plays a part. And it's entirely possible that Netflix is also partially at fault. Also note that this bug only happens in fullscreen mode (at least as far as I know), and Firefox (or any browser) does very little in fullscreen mode. Fixing (or working around) this kind of bug is a nightmare. There's no point even trying if you can't reproduce it reliably. And even if you can, it'll still be a lot of work -- possibly several weeks' work.
> There's no point even trying if you can't reproduce it reliably. I'd agree with that. I keep fiddling with settings, trying to alter things, to see if there's some setting or bit I can fiddle with. One thing I did notice is that the debugging screen (shift-option-ctrl-D) reports that Silverlight is using hardware acceleration mode even when I've unchecked that option (even when I uncheck it, exit Firefox, restart). I wonder if hardware is related to this?
> I wonder if hardware is related to this? At this point, just about anything's possible :-( If you're able to test on different hardware, please do so. Also test on different versions of OS X.
Testing on different hardware is about the only thing I haven't tried. I've had this issue since 10.6. I want to take a look at this myself, but I really have no time to do so within the next few months, either. But maybe this Spring...
Rimbosity, what you said about a hardware connection got me thinking. By any chance is the machine you see this bug on a Mac Mini, and does it have an HDMI connector (to an amplifier and/or a TV)? I know from email that Daniel Holbert has been testing on a Mac Mini, though he hasn't yet told me what kind of connector it uses.
(I'm using a Mac Mini, connected to a TV using a normal DVI connector - not HDMI)
Macbook Pro. It has one of those @#$&*( Apple mini-display connector things that requires a $35 adapter to use with any actual device. Here's the short version: Macbook Pro, 15-inch, Mid 2010 Processor: 2.53 GHz Intel Core i5 Memory: 8GB 1067 MHz DDR3 Graphics: NVIDIA GeForce GT 330M 256MB OS X 10.8.2. (12C60) Sometimes it's hooked up to a 2005-era 23" Cinema Display and sometimes it isn't; behavior's the same either way.
> Sometimes it's hooked up to a 2005-era 23" Cinema Display and > sometimes it isn't; behavior's the same either way. Are you saying that your two choices are to display on your laptop's built-in display or on an external Cinema Display, and that Netflix streaming works equally badly on each? Is your Cinema Display disconnected when you try to do Netflix streaming on the built-in display?
What I'm saying is that I've tried all of the following configurations, and get the same behavior from each: * Standalone laptop on built-in display * Laptop connected to cinema display through DVI converter on built-in display * Laptop connected to cinema display through DVI converter on cinema display * Laptop connected to Epson 8350 through HDMI converter on Epson 8350 I haven't tried it on the built-in display when connected to the Epson.
Thanks. I just wanted to make sure you'd tested with your laptop on its built-in display, while it wasn't connected to any other display. Seems like you have, and that it didn't make any difference to your results.
FWIW, I can't reproduce this bug anymore, using the same Mac mini & TV that used to reproduce it, back in comment 50. (Still connecting them using DVI, per comment 61, too.) Presumably some update to some software component fixed the problem. My current, working configuration is OS X 10.9, Silverlight 5.1.20913.0, and today's version of Aurora 28. (all up-to-date)
Juan, are you still seeing this or can we close this?
Flags: needinfo?(jbecerra)
I haven't noticed a difference in frame drops between the two modes in the latest versions of 30, 31, and 32. Then again, I no longer have a machine where to test this that resembles the one where the problem was originally reported.
Flags: needinfo?(jbecerra)
I'm going to resolve this as WFM since I can't reproduce anymore, per comment 66. (and unlike Juan, I am using a machine that I could originally reproduce this on)
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: