Closed Bug 800948 Opened 8 years ago Closed 7 years ago

Tab and little-arrows elements sometimes appear oversized in Preferences dialog with Retina display and no h/w acceleration

Categories

(Core :: Graphics, defect)

x86
macOS
defect
Not set

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox19 --- affected

People

(Reporter: mconley, Assigned: smichaud)

References

(Blocks 1 open bug)

Details

(Keywords: regression, Whiteboard: Regression window in comment 4)

Attachments

(4 files, 2 obsolete files)

Attached image Really tall tabs
Filing under XUL for now, though this might belong under Layout. I'm not exactly sure.

Steps to reproduce:

1) Procure a MacBook Pro with a Retina display
2) Download and run a copy of Thunderbird Daily
3) Open up the Preferences dialog, and switch to the Advanced or Attachments pane (you may need to close the dialog and repeat in order to expose the bug)

What happens?

The <tab>s in the <tabs> element look crazy tall and strange. Switching back and forth between panes, or causing the dialog to be backgrounded seems to resolve the issue.

See screenshot.

What's expected?

The tabs should look proper.


I've not been able to reproduce this on a Nightly of Firefox yet, so maybe this is something Thunderbird is doing wrong. Any ideas?
Is this a regression?
I suppose you could say that, yes.
Keywords: regression
If so, then a regression window would be needed here.
Sancus,

You're the only one I know in Thunderbird-land with access to a Retina display right now... are you able to find a regression window?

You might have used these before, but if not, they're handy: http://harthur.github.com/mozregression/

-Mike
Ok, I've got a regression window.

Last good Daily is on September 29th.
First bad is on September 30th.
Whiteboard: Regression window in comment 4
So bug 674373 probably.
Blocks: 674373
This is almost certainly fallout from bug 674373.  But it's odd that similar problems don't show up in the Firefox preferences dialog.  I suppose the Firefox dialog's code must (inadvertently) work around it.

Another odd thing:  I can see this problem in any of the panes that have tabs.  But I almost always see it only once per preferences dialog "session" (to see it again I have to close the dialog and reopen it).  I also never see it in the pane that opens when the dialog opens -- I have to switch to another pane to see it.
Another possibility:

Does Thunderbird have its own equivalent of the Cocoa widgets "native theme" code at widget/cocoa/nsNativeThemeCocoa.mm?  We had to fiddle with that code to get the backgrounds of "native" UI objects to display at the right size in HiDPI mode.  Maybe the same strategy can be used in Thunderbird's own equivalent (if it exists).
(In reply to Steven Michaud from comment #9)
> Another possibility:
> 
> Does Thunderbird have its own equivalent of the Cocoa widgets "native theme"
> code at widget/cocoa/nsNativeThemeCocoa.mm?  We had to fiddle with that code
> to get the backgrounds of "native" UI objects to display at the right size
> in HiDPI mode.  Maybe the same strategy can be used in Thunderbird's own
> equivalent (if it exists).

Hm, I don't think so.  A glance around comm-central doesn't turn up anything like that. Can you confirm that, Mark?
If Thunderbird doesn't have its own equivalent of nsNativeThemeCocoa.mm, this is probably a bug in nsNativeThemeCocoa.mm itself.
I don't know of anything like nsNativeThemeCocoa, I'm sure we don't have the equivalent.
It could be within nsNativeThemeCocoa itself, or alternatively it could be an error in code that's setting up the rendering context before calling in to the native theme code. nsNativeThemeCocoa is responsible for deciding how tall the tabs should be (GetMinimumWidgetSize) and actually drawing them (DrawSegment, called by DrawWidgetBackground), but these depend on an nsRenderingContext that is provided by the caller. Maybe there's some case where it isn't set up properly.
Aha - I can reproduce this in Firefox if I disable hardware acceleration. (And conversely, if I explicitly set layers.acceleration.disabled to false in Thunderbird Daily, I can no longer reproduce it there.) So it looks like an issue specific to the non-accelerated drawing path.
Incidentally, this problem can also appear with the "little arrows" control that appears next to textboxes with values that can be incremented/decremented, such as the "Auto Save every [  ] minutes" option in Composition / General.
Here's a recipe to consistently reproduce the problem with Firefox Nightly on a Retina MacBook:

1. Open the Preferences window and switch to the Advanced panel, General tab.
2. *UN*check the Use hardware acceleration checkbox.
3. Switch to the Network tab (because it has a little-arrows control that we'll be observing).
4. Quit and re-launch Firefox, so that it is running without hardware acceleration.
5. Open the Preferences window; it should re-open showing the same panel and tab as before. Note that the tabs and the little-arrows control look fine.
6. Click on a different Preferences panel (e.g. General), then click back on Advanced. Note the over-inflated tabs and little-arrows control.
7. Repeat step 6; note that now the controls in Advanced appear correct again. They'll remain correct until the dialog is closed and re-opened, then you can repeat the above dance.

Tracing confirms that the coordinates being passed to nsNativeThemeCocoa::DrawWidgetBackground are exactly the same in the "good" and "bad" cases; the problem must somehow be related to transforms in the context/layers/widgets involved.
Summary: Tab elements appears strangely tall sometimes in Thunderbird's preferences dialog with Retina display. → Tab and little-arrows elements sometimes appear oversized in Preferences dialog with Retina display and no h/w acceleration
I'm wondering if this is caused by an inconsistency or mismatch in how resolution is handled somewhere down in the thebes/cairo area. 

I added some debugging code to print out the Current Transform Matrix (CTM) and UserSpaceToDeviceSpaceTransform of the CGContext that's returned by nativeDrawing.beginDrawing() within DrawWidgetBackground. The results are... curious.

With HWA enabled, I'm consistently seeing matrices where the scaling of CTM and UserToDevice match (usually it's 2.0, sometimes 1.0, but the magnitude of the scale in the two matrices always match).

However, with HWA disabled, I'm often - but not always - seeing a mismatch between these matrices. Typically, the CTM has a scale of 2.0, and the UserToDevice transform has 4.0. (Which seems surprising - it makes sense to see a scale of 2.0 somewhere when we're in HiDPI mode, but why 4.0?) In particular, when the Preferences dialog is open and its tabs are being drawn, I see this 2.0/4.0 scale mismatch when the tabs are drawn *correctly*. But at step 6 of the STR in comment 16, when the tabs display over-inflated, the matrices both have a scale of 2.0. At step 7, where we switch away and back again, and the tabs correct themselves, the matrices return to their 2.0/4.0 scales.

I don't really understand where these transforms are being set up, or why they're inconsistent (the "same" pane has different UserToDevice transforms at step 6 and after step 7 of the STR above), but I suspect they may indicate that we're not always handling the HiDPI scaling factor as cleanly as we should (why is UserToDevice ever 4.0?).

I note that if I disable the code to use the cairo surface's CGContext at
  http://mxr.mozilla.org/mozilla-central/source/gfx/thebes/gfxQuartzNativeDrawing.cpp#42
(by making that condition always FALSE, so that we always take the else clause and create a new gfxQuartzSurface), I can no longer reproduce the problem here. The CTM and UserToDevice matrices in the resulting CGContext then seem to always have a scale factor of 1.0 (in both HWA and non-HWA cases), and the controls consistently render correctly.

However, such a hack would presumably carry a significant performance cost - indeed, I'd say that subjectively the browser UI feels a little more sluggish (e.g. when animating the Preferences dialog when switching panels), at least in my debug build.
Debugging patch used to observe scaling in CGContext matrices while drawing native widgets.
Moving this to Graphics, as I think the problem is somehow related to mixed-up handling of resolution/transforms (see above), maybe somewhere around gfxQuartzNativeDrawing or the Cairo and/or Layers code it interacts with.
Component: XUL → Graphics
The problem here only seems to occur when we hit a codepath that uses the cairo_quartz_surface_create_cg_layer function that was introduced in bug 568189, through gfxQuartzSurface::CreateSimilarSurface. If we instead just call cairo_surface_create_similar, the issue goes away.
Duplicate of this bug: 812254
Also happens in Firefox 2012-11-14 on 10.8.2; see Bug 812254 for a screenshot.
Attached patch Possible fix (obsolete) — Splinter Review
Believe it or not, I think I've found a one-line fix for this bug!

Turns out that it's caused by a bug in Apple's CUIDraw() -- under certain circumstances (about which more below), it can get confused and draw objects at the wrong size.

This appears to happen when CUIDraw() tries to rescale the object from its "original" size (presumably specified in graphics stored somewhere by the OS).  But it also turns out there's a way to prevent this rescaling -- by adding "kCUIScaleKey" (with any value) to the options passed to CUIDraw().

As best I can tell, this bug's specific problems only happen when CUIDraw() is called from nsNativeThemeCocoa::DrawSegment().  So I've only added the kCUIScaleKey option to that call.

In principle we may also want to add it to the other calls we make to CUIDraw().  But wherever an option currently specifies coordinates in "display pixels", we'd probably need to change them to device pixels.

I discovered kCUIScaleKey by looking at the assembler code for CUIDraw() (more specifically for CUIRenderer::Draw(CGRect, CGContext*, __CFDictionary const*, __CFDictionary const**), a non-exported method called from CUIDraw()).  It checks for this value by calling for CFDictionaryGetValue().  But if found it throws away the result and just copies from a global CFAffineTransform variable (6 floats, presumably a default value, probably identity) to a local one and skips ahead several hundred lines.

I've started a tryserver build, which should be available in a few hours.
Assignee: nobody → smichaud
Status: NEW → ASSIGNED
6 floats -> 6 doubles
CGContextGetType() is an undocumented method (already used in cairo-quartz) that returns a CGContextRef's "type" (an integer value).  CGContextRefs created by CGBitmapContextCreate() or CGBitmapContextCreateWithData() (i.e. bitmaps) are type '4'.  "Cocoa" CGContextRefs (those returned by -[NSGraphicsContext graphicsPort]) are type '3'.  And CGContextRefs associated with a CGLayer (returned by CGLayerGetContext()) are type '0'.

Bitmap CGContextRefs (type 4), when unscaled, always have the same scaling in "user space" and "device space".  Cocoa CGContextRefs (type 3) have the same user and device scaling in non-HiDPI mode, but in HiDPI mode the device space scaling is twice the user space scaling.

CGLayer CGContextRefs (type 0) are more complex:  If a CGLayer was created (using CGLayerCreateWithContext()) from a bitmap CGContextRef, its CGContextRef's user space and device space scaling are the same (as they are for the "original" CGContextRef).  But if a CGLayer was created from a Cocoa CGContextRef, its CGContextRef's device scaling is (in HiDPI mode) twice its user space scaling (again as they are for the "original" CGContextRef).

Furthermore, a CGContextRef's user space and device space scaling *both* change if you rescale the CGContextRef.  So calling CGContextScaleCTM(2.0, 2.0) on a Cocoa CGContextRef (or on a CGLayer CGContextRef that originated from a Cocoa CGContextRef) gives it a user space scale of 2.0 and a device space scale (in HiDPI mode) of 4.0.  This, Jonathan, is what you saw in comment #17 and following.

We currently only use CGContextyGetUserSpaceToDeviceSpaceTransform() twice in the tree (both in nsNativeThemeCocoa.mm).  And this unexpected behavior doesn't break any of the code that uses it.  But we'll need to keep this in mind for the future.  (Later I'll add a comment somewhere in nsNativeThemeCocoa.mm.)  Note that, starting with Lion, there's also an undocumented CGContextGetDefaultUserSpaceToDeviceSpaceTransform() whose results don't change if the CGContextRef it's called on has been scaled.
As best I can tell, CUIDraw() only gets confused with CGLayer CGContextRefs (type 0) that were created from bitmap CGContextRefs (type 4).  So in principle we could only apply my fix if we're going to pass this kind of CGContextRef to CUIDraw() (and if we're in HiDPI mode).  But getting this information would require us to add public methods to cairo-quartz.h -- which I'd prefer not to do unless it's really necessary.
I haven't yet tested my patch on OS X 10.6.8.  So it's possible we'll need to use it only on OS X Lion and up.  (I've already tested it on Mountain Lion, and saw no problems.  I also found the same usage of kCUIScaleKey in the assembler code for Mountain Lion's CUIDraw() and friends.
(In reply to Steven Michaud from comment #23)
> Created attachment 683759 [details] [diff] [review]
> Possible fix
> 
> Believe it or not, I think I've found a one-line fix for this bug!

Fantastic!

> I've started a tryserver build, which should be available in a few hours.

I tried your tryserver build (briefly, so far). The good news is that I could no longer reproduce the oversized tab headers, using steps that previously reproduced them very consistently. So this does indeed appear to have solved that.

The not-quite-so-good news is that (understandably, given where the fix is applied) this doesn't resolve the problem of the "little arrows" control becoming oversized, which can be seen in the Preferences / Advanced / Network panel after an appropriate dance of panel-switching. And nsNativeThemeCocoa::DrawSpinButtons, which I assume is what draws them, doesn't use CUIDraw. So to apply this fix there, I guess we'd need to rework DrawSpinButtons to be CUIDraw-based, but I haven't looked in to just what that would involve.
> And nsNativeThemeCocoa::DrawSpinButtons, which I assume is what
> draws them, doesn't use CUIDraw.

Interesting.  So the bug may not actually be in CUIDraw().  Or maybe
the bug is in Apple code used by CUIDraw() and other methods.

I'm going away for Thanksgiving, so I only have a couple more hours
this week to work on this bug.  I'll start in again next week, though.
nsNativeThemeCocoa::DrawSpinButtons() uses the Apple HIThemeDrawButton() method.

Next week I'll dig around in its assembly code to see what I can find.
The HIToolbox framework (where the HITheme... methods live) links CUIDraw().  So the bug may be there after all.  I'll see if I can change how those methods use CUIDraw() ... if they use them.  Otherwise, as you say, we'll probably need to switch from using HIThemeDrawButton() to using CUIDraw().
HIThemeDrawButton() does call CUIDraw() (indirectly).  So we can (in gdb) observe what options it passes to CUIDraw().  So it shouldn't be hard to figure out how to replace calls to HIThemeDrawButton() with calls to CUIDraw().

Anyone know of a "strings" variant that can search for 16-bit Unicode strings?  We could use it to search the HIToolbox framework for the string "kCUIScaleKey".  If the HIToolbox framework knows about kCUIScaleKey and we can trick it into using it on calls to the HITheme... methods, that'd be easier still.
For what it's worth, here's a tryserver build made from my patch from comment #23:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/smichaud@pobox.com-4ccd7559958e/try-macosx64/firefox-20.0a1.en-US.mac.dmg

There were no test failures -- not even spurious ones.
> Anyone know of a "strings" variant that can search for 16-bit Unicode strings?

The Windows-based WinHex hex editor can do it (http://www.x-ways.net/winhex/).

The Lion HIToolbox framework doesn't contain the "kCUIScaleKey" string, either as ASCII or as Unicode (16-bit).  So HIToolbox presumably doesn't know about the kCUIScaleKey trick.  So we'll probably have to replace HIThemeDrawButton() with CUIDraw() -- and maybe also other HITheme... methods.
Just for grins, I grepped the /Applications and /System/Library directories on Lion and Mountain Lion for "kCUIScaleKey" (ASCII), to see which Apple apps and frameworks (if any) know about it.  On Lion I found no matches (aside of course from the CoreUI framework itself).  But on Mountain Lion the AppKit framework matches.

Later I'll try to find out which part of the Mountain Lion AppKit uses kCUIScaleKey.
FWIW, the brief CoreUI intro at http://www.theregister.co.uk/2009/01/12/mac_secrets_coreui/ includes a fragment with relevant dictionary entries for the little-arrows control. It's a bit old (and possibly incomplete?), but might at least provide some clues for converting DrawSpinButtons.
(Following up comment #35)

I've found two Objective-C methods in the MountainLion AppKit framework that reference kCUIScaleKey:

-[NSThemeFrame _cuiOptionsForWindowType:(CFStringRef)arg1
                              topHeight:(double)arg2
                      shouldSetScaleKey:(BOOL)arg3];
-[NSButtonCell _bezelContentsFromCoreUIWithFrame:CGRect)arg1
                                          inView:(id)arg2]

Both return an 'id'.  For the first method this 'id' is an NSDictionary*/CFDictionaryRef.  Both are undocumented, and exist only on MountainLion (not on Lion).

Both add a kCUIScaleKey setting to a CFDictionary that will presumably be passed as "options" to a call to CUIDraw().  But interestingly both set its value to an NSNumber made from the result of calling 'backingScaleFactor' on either the return value of [self window] (the first method) or arg2 (an NSView*, the second method).

So Apple apparently intends (at some point in the future) to change the code of CUIDraw() to no longer ignore the value of the kCUIScaleKey "option" (as it does now, on both Lion and MountainLion).

In my next revision, I'll change my patch to emulate this behavior.
I was not able to come up with a better solution here based on the CGContext{Get,Set}BaseCTM functions - for one thing, it doesn't appear to be possible to use SetBaseCTM with a bitmap context, which is often what we have. It sounds like Steven is on the track of a solution based on other CUIDraw magic; however, in the meantime I'd like us to take the simple patch here, which I think carries minimal risk, so that we have something we can uplift to go with the initial HiDPI support. If/when Steven's CUIDraw stuff is ready and verified to work everywhere, we can easily revert this.
Attachment #687191 - Flags: review?(jmuizelaar)
Comment on attachment 687191 [details] [diff] [review]
avoid use of cairo_quartz_surface_create_cg_layer to work around HiDPI context scaling mismatch issues.

Steven, is it OK with you if we do this, at least for now? AFAICT this avoids the problem situation, at the risk of a slight perf hit for non-accelerated windows (so it shouldn't hurt the primary browsing experience, only things like dialogs/sheets/panels - and it doesn't actually seem to be significant there, even in my debug build).

We can of course revert this once your CUIDraw stuff is ready, but I see this as a minimum-risk option that we can push to get uplifted to go out alongside the rest of the HiDPI support that's already on aurora (and maybe beta).
Attachment #687191 - Flags: review?(smichaud)
Comment on attachment 687191 [details] [diff] [review]
avoid use of cairo_quartz_surface_create_cg_layer to work around HiDPI context scaling mismatch issues.

This looks fine, in principal, as a stopgap fix.

I do wonder about the performance hit, but Jeff should know more about that.

I've gotten distracted by bug 804606, which is a topcrasher.  But I hope to get back to this bug soon.

I think I only need 2-3 more days of work to finish my patch.
Attachment #687191 - Flags: review?(smichaud) → review+
I can very easily reproduce this by just moving the Thunderbird preference window between the Macbook's retina screen and an external monitor, no need to close the preference window to see the bug again.

This may not be useful information any more as the problem seems to already be well understood, but I thought I would mention in anyway, as it may help QA later to verify the bug is fixed.
Comment on attachment 687191 [details] [diff] [review]
avoid use of cairo_quartz_surface_create_cg_layer to work around HiDPI context scaling mismatch issues.

Review of attachment 687191 [details] [diff] [review]:
-----------------------------------------------------------------

We need to understand the performance impact of this before we take it. I don't have a good intuition, but it feels like it could be bad. I'd expect that this may avoid a bunch of vm_copy copy-on-write stuff. Basically, we end up calling CGBitmapContextCreateImage on the source context to create a CGImage which we paint CGContextDrawImage into the destination context. This does a vm_copy behind the scenes which has typically been a cause of performance problems.
Attachment #687191 - Flags: review?(jmuizelaar) → review-
This week's been eaten by bug 804606, and maybe also part of next week.  But if we can hang on til the end of next week, there's a reasonable chance I'll have had time by then to finish my patch for this bug.
That'd be great - and if that comes through, we could undo the band-aid, but I'd be happier if we had at least -something- in the tree in the meantime to fix the visual glitches this is causing.
Roc, do you have specific examples of things that gained a significant perf boost from bug 568189 (where cairo_quartz_surface_create_cg_layer was introduced)? Would be nice to have some testcases where we could compare performance and see what the impact of disabling this would be.
Flags: needinfo?(roc)
IIRC it improved the performance of blitting the backbuffer with BasicLayers on Mac.

So you might want to try measuring that.
Flags: needinfo?(roc)
(using a high-res timer, perhaps)
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #47)
> (using a high-res timer, perhaps)

TimeStamp on OS X uses mach_absolute_time which should give sufficient resolution for this case.
It looks like the main place we use gfxQuartzSurface::CreateSimilarSurface is from BasicLayerManager::EndTransactionInternal, so I added instrumentation to report the total time taken by EndTransactionInternal in the cases when it actually uses CreateSimilarSurface (which it doesn't always).

In a sequence of actions <Launch browser; Open Preferences window; Cycle through each Preferences panel in turn; Quit>, I see a total of about 7-8 calls to CreateSimilarSurface (roughly corresponding to one per user action); the associated EndTransactionInternal calls take various times ranging from 250µs to 30ms. The increase caused by the patch here varied from almost insignificant (<10µs) up to about 750µs on the slowest EndTransactionInternal.

I also timed pulling down the awesomebar menu of recent pages, which involves an EndTransactionInternal taking a little over 4ms; again, the patch here added about 750µs to that time.

So there is a measurable cost here - but ISTM that a penalty of less than a millisecond on these kind of user interactions is not excessive, for the sake of avoiding the visual brokenness of this bug. While we may well end up with a better fix from Stephen eventually, I'd like us to get this into the tree for testing as a potential band-aid in the meantime.
I've actually got a fix for bug 804606 (at least I think so).  So I may still be able to make the end-of-this-week deadline I set for myself in comment #43.

My fix, once I'm done with it, should be very simple and have no performance penalty.  Let's wait until Friday to see if I can get my patch done by then.
I'm making good progress on this, but I won't finish it today.

I should be able to finish it on Monday, though.

I'm writing a replacement for HIThemeDrawButton() that uses CUIDraw() directly.  To find out which "options" to send to CUIDraw() I've written an interpose library to hook HIThemeDrawButton() and CUIDraw(), which I'm using to discover what the options are for every possible parameter passed to HIThemeDrawButton().  This is laborious, but the work should be done in just a few more hours.
(In reply to Jonathan Kew (:jfkthame) from comment #49)
> I also timed pulling down the awesomebar menu of recent pages, which
> involves an EndTransactionInternal taking a little over 4ms; again, the
> patch here added about 750µs to that time.

On what sort of machine?

What if you try smooth-scrolling a page in a large window? What sort of % slowdown do you see?
Attached patch Fix rev1 (obsolete) — Splinter Review
Here's the fix I promised.

Rather than entirely replace HIThemeDrawButton(), I decided just to replace it for "littlearrow" objects (kThemeIncDecButton objects in HITheme-speak).

Turns out there are lots of HITheme capabilities that can't be translated when calling CUIDraw() (or which at least aren't translated when the HIToolbox framework calls CUIDraw() from HITheme functions).  So I decided it'd be best to continue using HITheme functions where we don't have to work around this bug.

So is this bug done?  Not on your life! :-(

When I went to test my build, I found this bug has somehow gotten "fixed" in current trunk code.  Or at least the symptoms are now different, so that our old STRs no longer work.

So now we've got to decide whether this mysterious "fix" is good enough that we don't have to land any patch here, or otherwise if we need to come up with some entirely new solution.
Attachment #683759 - Attachment is obsolete: true
Here's the "degression" range for our mysterious spontaneous "fix":

firefox-2012-12-13-03-07-51-mozilla-central
firefox-2012-12-14-03-08-27-mozilla-central

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=edd45de440ba&tochange=b11065872128
Yup, I can confirm I don't see the problem any longer with the previously-reliable STR, as of the 2012-12-14 nightly.

It'd be nice to figure out exactly what fixed this, by further bisection of that range - maybe something about bug 811157 or bug 798245? That's pure speculation though, just from briefly skimming the checkin comments.
It's one of the patches for bug 805745.  I'll shortly find out which one.
Here's the patch that "fixed" this bug:

http://hg.mozilla.org/mozilla-central/rev/9f6c579151c5

 Bug 805745. Move the forced repaint from the Paint notification to the WillPaint notification. r=mattwoodrow
author	Timothy Nikkel <tnikkel@gmail.com>
	Wed Dec 12 15:57:08 2012 -0600 (at Wed Dec 12 15:57:08 2012 -0600)

I'd dearly love for this to be a real fix, and for me never to have to think about this bug again :-)

But I'm afraid I don't have the time to check it out.  Yes, I'm now done with bug 804606.  But now I've been eaten alive by bug 821304.
Attached patch Fix rev2Splinter Review
For what it's worth, here's an update to my patch.

And here's a tryserver build made from it:
http://ftp-scl3.mozilla.com/pub/mozilla.org/firefox/try-builds/smichaud@pobox.com-343dc5d478d1/try-macosx64/firefox-20.0a1.en-US.mac.dmg
Attachment #693137 - Attachment is obsolete: true
Mike, Florian (or anyone else who's seen this bug):

Do you still see it with current trunk builds (of FF or Thunderbird)?  If so please give us STR.

If you can't, I suggest just letting this bug ride, but leaving it open.
(In reply to Steven Michaud from comment #59)
> Mike, Florian (or anyone else who's seen this bug):
> 
> Do you still see it with current trunk builds (of FF or Thunderbird)?  If so
> please give us STR.
> 
> If you can't, I suggest just letting this bug ride, but leaving it open.

Unfortunately, I no longer have a Retina display to tinker with. But I do believe Florian does...
Flags: needinfo?(florian)
(In reply to Steven Michaud from comment #59)
> Mike, Florian (or anyone else who's seen this bug):
> 
> Do you still see it with current trunk builds (of FF or Thunderbird)?

I just updated my debug Thunderbird build, and I can't reproduce any more with the STRs I gave in comment 41.

I see a different bug when moving the preferences window between the built-in retina screen and a non-retina external screen. The content of the pref window flashes briefly at the wrong resolution (it appears way too big for a split second when the window arrives on the external monitor, and way too small when the window arrives on the retina screen). Not sure if it's related or not.
Flags: needinfo?(florian)
Thanks for the info.

> Not sure if it's related or not.

It's not related.  This bug is about particular UI objects being drawn at the wrong size.  You're talking about an entire window being (temporarily) drawn at the wrong size.
(In reply to Steven Michaud from comment #59)

> Do you still see it with current trunk builds (of FF or Thunderbird)?  If so
> please give us STR.

I no longer see my duplicate issue (Bug 812254) with current FF Nightly.
I changed my mind about leaving this bug open.

Please reopen if you start seeing it again on the trunk.
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.