The CSS viewport computation for desktop mode was incorrect. The end result was
that the right amount of CSS pixels was visible on the screen, but the layout
properties were incorrect (so elements that were width:100% would use a different
width than intended). This caused content to be truncated and otherwise
mis-rendered in desktop mode.
We're changing the definition of each of the use counter histograms.
Therefore, they need new names, so as to not throw wrenches into the
server-side machinery. This renaming is the most straightforward way to
do things and similar to how we have renamed other histograms before.
These histograms will be used in conjunction with the revised use
counter histograms to ascertain the number of pages that don't use
particular features. The associated comment in nsDocument.cpp explains
how things work.
There are many sub-classes of nsExpirationTracker. In order to distinguish them
nicely in the logging of timer firings, it's necessary to manually name each
one. (This wouldn't be necessary if there was a way to stringify template
parameters, but there isn't.)
We're changing the definition of each of the use counter histograms.
Therefore, they need new names, so as to not throw wrenches into the
server-side machinery. This renaming is the most straightforward way to
do things and similar to how we have renamed other histograms before.
These histograms will be used in conjunction with the revised use
counter histograms to ascertain the number of pages that don't use
particular features. The associated comment in nsDocument.cpp explains
how things work.
This fixes nsIHttpChannel::GetRequestHeader() and
nsIHttpChannel::GetResponseHeader() to always empty out their string
argument even when they fail. This prevents programming mistakes of
passing the same string object to multiple of these calls and using the
string value without checking the nsresult error code, since otherwise
the string value may be unchanged from a previous call.
Note that this doesn't affect JS consumers of these APIs since we only
empty out the string argument in case the method fails, which will be
translated to a JS exception, and the JS code will never get to see the
emptied string.
The browser.ui.zoom.force-user-scalable pref can be modified by the user from
the Fennec settings screen, and allows them zoom pages despite the meta-viewport
tag that might otherwise restrict zooming. This effectively ignores the effect
of the user-scalable, minimum-scale, and maximum-scale meta-viewport tokens.
This is a long-standing issue that has thus far never been exposed because
the values modified in this patch have not been used (desktop mode only exists
on Fennec, and Fennec does it's own computation for these values in browser.js).
However upcoming patches will change Fennec to use this, and so this issue needs
to be corrected.
In the case of DisplayWidthHeight viewports, setting the allowDoubleTapToZoom
flag to true is fine because the ZoomConstraintsClient code will flip it back
to false based on the width of the CSS viewport. Setting it to true in the
GetViewportInfo code allows us to maintain the invariant that the default value
of allowDoubleTapToZoom is the same as the initial value of allowZoom.
