This is a drive-by fix to turn a division into a multiplication. It also
is more correct in that the existing code attempts a divide-by-zero if
aNewViewport.width is zero. The updated code will instead return a zoom
of zero in such a case.
Differential Revision: https://phabricator.services.mozilla.com/D32909
--HG--
extra : rebase_source : 83ab76092596d7feda11f66d83c022d3d1e4acd3
extra : source : 2a85e3af81bbe475217ecdf16ce7c5a1a7985a21
The existing math is attempting to adjust the display scale ratio to
prevent the new size from landing outside the min/max zoom bounds. This
introduces unwanted side effects that can be avoided by simply clamping
to min/max at the end. The remaining math correctly handles the case
where the zoom has ALREADY been clamped, which is the only important
case.
Differential Revision: https://phabricator.services.mozilla.com/D32908
--HG--
extra : rebase_source : 3767a50a7d88ceced7b0b3d5979020296f91d7a2
extra : source : 262d2cad64079c343e35b757ac642b231d50e0df
This is a drive-by fix to turn a division into a multiplication. It also
is more correct in that the existing code attempts a divide-by-zero if
aNewViewport.width is zero. The updated code will instead return a zoom
of zero in such a case.
Differential Revision: https://phabricator.services.mozilla.com/D32909
--HG--
extra : moz-landing-system : lando
The existing math is attempting to adjust the display scale ratio to
prevent the new size from landing outside the min/max zoom bounds. This
introduces unwanted side effects that can be avoided by simply clamping
to min/max at the end. The remaining math correctly handles the case
where the zoom has ALREADY been clamped, which is the only important
case.
Differential Revision: https://phabricator.services.mozilla.com/D32908
--HG--
extra : moz-landing-system : lando
This is a drive-by fix to turn a division into a multiplication. It also
is more correct in that the existing code attempts a divide-by-zero if
aNewViewport.width is zero. The updated code will instead return a zoom
of zero in such a case.
Differential Revision: https://phabricator.services.mozilla.com/D32909
--HG--
extra : moz-landing-system : lando
The existing math is attempting to adjust the display scale ratio to
prevent the new size from landing outside the min/max zoom bounds. This
introduces unwanted side effects that can be avoided by simply clamping
to min/max at the end. The remaining math correctly handles the case
where the zoom has ALREADY been clamped, which is the only important
case.
Differential Revision: https://phabricator.services.mozilla.com/D32908
--HG--
extra : moz-landing-system : lando
This is a drive-by fix to turn a division into a multiplication. It also
is more correct in that the existing code attempts a divide-by-zero if
aNewViewport.width is zero. The updated code will instead return a zoom
of zero in such a case.
Differential Revision: https://phabricator.services.mozilla.com/D32909
--HG--
extra : moz-landing-system : lando
The existing math is attempting to adjust the display scale ratio to
prevent the new size from landing outside the min/max zoom bounds. This
introduces unwanted side effects that can be avoided by simply clamping
to min/max at the end. The remaining math correctly handles the case
where the zoom has ALREADY been clamped, which is the only important
case.
Differential Revision: https://phabricator.services.mozilla.com/D32908
--HG--
extra : moz-landing-system : lando
And with some tidying some comments and removing stray #include "gfxPrefs.h"
Differential Revision: https://phabricator.services.mozilla.com/D31468
--HG--
extra : moz-landing-system : lando
And with some tidying some comments and removing stray #include "gfxPrefs.h"
Differential Revision: https://phabricator.services.mozilla.com/D31468
--HG--
extra : moz-landing-system : lando
And with some tidying some comments and removing stray #include "gfxPrefs.h"
Differential Revision: https://phabricator.services.mozilla.com/D31468
--HG--
extra : moz-landing-system : lando
This change was originally added as a drive-by optimization in Bug 1501665.
The early-exit apparently routes around a needed side effect in the case
where resolution is re-set to its current value.
Differential Revision: https://phabricator.services.mozilla.com/D28566
--HG--
extra : moz-landing-system : lando
elementFromPoint-002.html, elementFromPoint-003.html and dialog-showModal.html
use document.elementFromPoint with a given point which is calculated from the
value returned by getBoundingClientRect() for a 100% width element. Before
this change, the given point is outside of view because there is no viewport
meta tag in the documents so that elementFromPoint fails. After this change, the
documents fit to the visual viewport so that elementFromPoint works as expected.
Differential Revision: https://phabricator.services.mozilla.com/D16155
--HG--
extra : moz-landing-system : lando
Currently the MobileViewportManager leaves somethings permanently changed
even after it is destroyed: it may have changed the resolution of
the Document, and it may have set a fixed size for the visual viewport.
Both of these changes need to be un-done to return to normal display of
the Document.
Differential Revision: https://phabricator.services.mozilla.com/D17999
--HG--
extra : source : 088dc24eabc75eea96301d50550e0a8817f5f809
Currently the MobileViewportManager leaves somethings permanently changed
even after it is destroyed: it may have changed the resolution of
the Document, and it may have set a fixed size for the visual viewport.
Both of these changes need to be un-done to return to normal display of
the Document.
Differential Revision: https://phabricator.services.mozilla.com/D17999
--HG--
extra : moz-landing-system : lando
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
There is no reason to use nsAtoms*, it's error prone, i.e. the function
can take arbitrary nsAtoms*.
Depends on D15339
Differential Revision: https://phabricator.services.mozilla.com/D15340
--HG--
extra : moz-landing-system : lando
This is a big step in order to merge both.
Also allows to remove some very silly casts, though it causes us to add some
ToSupports around to deal with ambiguity of casts from nsIDocument to
nsISupports, and add a dummy nsISupports implementation that will go away later
in the series.
Differential Revision: https://phabricator.services.mozilla.com/D15352
The tracking is done using nsAtom origins, similarly to how updates to the
scroll offset are tracked.
Currently, APZ still uses some heuristics to deduce that the main thread
originated a resolution change in some cases, but the intention is to try
to remove those and rely only on this mechanism in the future.
Differential Revision: https://phabricator.services.mozilla.com/D13741
--HG--
extra : moz-landing-system : lando