Backed out changeset a74ef371c48f (bug 1087964) for failing elementFromPoint.html on OSX 10.10 debug. r=backout
authorSebastian Hengst <archaeopteryx@coole-files.de>
Thu, 12 May 2016 13:19:00 +0200
changeset 297176 fd319e90068059710f3e753c8adb52902f86d042
parent 297175 7fa6df3f85dca80d04ca10c25f7f5f4743880b2b
child 297177 05366ca62a430c90e3d2f99bde140674b2172102
push id30253
push usercbook@mozilla.com
push dateFri, 13 May 2016 09:59:43 +0000
treeherdermozilla-central@5a2deb5a9b09 [default view] [failures only]
perfherder[talos] [build metrics] [platform microbench] (compared to previous push)
reviewersbackout
bugs1087964
milestone49.0a1
backs outa74ef371c48f64d673d2790557a29aed9b409346
first release with
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
last release without
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
Backed out changeset a74ef371c48f (bug 1087964) for failing elementFromPoint.html on OSX 10.10 debug. r=backout
view/nsView.cpp
widget/cocoa/nsCocoaWindow.mm
--- a/view/nsView.cpp
+++ b/view/nsView.cpp
@@ -335,17 +335,36 @@ void nsView::DoResetWidgetBounds(bool aM
   bool changedSize = curBounds.Size() != newBounds.Size();
 
   // Child views are never attached to top level widgets, this is safe.
 
   // Coordinates are converted to desktop pixels for window Move/Resize APIs,
   // because of the potential for device-pixel coordinate spaces for mixed
   // hidpi/lodpi screens to overlap each other and result in bad placement
   // (bug 814434).
-  DesktopToLayoutDeviceScale scale = dx->GetDesktopToDeviceScale();
+  DesktopToLayoutDeviceScale scale = widget->GetDesktopToDeviceScale();
+
+#ifdef XP_MACOSX
+  // On OS X, this can be called before Cocoa has updated the backing scale
+  // factor of our widget, in which case |scale| is wrong here. To work
+  // around this, we check the device context and override |scale| if it
+  // doesn't match. (This happens when a popup window that has previously
+  // been created and hidden is being moved between hi- and lo-dpi screens,
+  // but is not currently visible; Cocoa doesn't notify it of the scale
+  // factor change until it gets shown on the new screen, which is too late
+  // for us because we'll have already done the computations involving scale
+  // here to move/size it.)
+  // It might be better to avoid this by keeping calculations such as
+  // CalcWidgetBounds entirely in appUnits, rather than using device pixels,
+  // but that seems like a more extensive and potentially risky change.
+  int32_t appPerDev = dx->AppUnitsPerDevPixelAtUnitFullZoom();
+  if (NSToIntRound(60.0 / scale.scale) != appPerDev) {
+    scale = DesktopToLayoutDeviceScale(60.0 / appPerDev);
+  }
+#endif
 
   DesktopRect deskRect = newBounds / scale;
   if (changedPos) {
     if (changedSize && !aMoveOnly) {
       widget->ResizeClient(deskRect.x, deskRect.y,
                            deskRect.width, deskRect.height,
                            aInvalidateChangedSize);
     } else {
--- a/widget/cocoa/nsCocoaWindow.mm
+++ b/widget/cocoa/nsCocoaWindow.mm
@@ -1583,17 +1583,17 @@ NS_IMETHODIMP nsCocoaWindow::Resize(doub
                                     bool aRepaint)
 {
   return DoResize(aX, aY, aWidth, aHeight, aRepaint, false);
 }
 
 // Coordinates are desktop pixels
 NS_IMETHODIMP nsCocoaWindow::Resize(double aWidth, double aHeight, bool aRepaint)
 {
-  double invScale = 1.0 / BackingScaleFactor();
+  double invScale = 1.0 / GetDefaultScale().scale;
   return DoResize(mBounds.x * invScale, mBounds.y * invScale,
                   aWidth, aHeight, aRepaint, true);
 }
 
 NS_IMETHODIMP nsCocoaWindow::GetClientBounds(mozilla::LayoutDeviceIntRect& aRect)
 {
   NS_OBJC_BEGIN_TRY_ABORT_BLOCK_NSRESULT;