Per froydnj in bug 1186064 comment #23, "it makes sense to proceed with removing
MSVC 2013 support." This commit does that.
We also go a step further and require VS2015 Update 2 instead of just
update 1. This temporarily brings us down to just 1 officially supported
Visual Studio version. However, VS2015u3 was just released and is
unofficially supported.
Since MOZ_CRT is no longer set, references to it have been removed.
MozReview-Commit-ID: 8MUR6qLzQA5
--HG--
extra : rebase_source : 8f5061080a3d56dd484f9be03649fb65f0145f67
Use ReconstructFrame to replace NS_STYLE_HINT_FRAMECHANGE in many places, such
as HTML*Element::GetAttributeChangeHint and HTMLFrameSetElement::SetAttr.
MozReview-Commit-ID: EHbc4RMeuu0
--HG--
extra : rebase_source : f5163608c88362595ef5af5fcd36fa64c9c79ce7
Use ReconstructFrame | (any ther bits needed) to replace
NS_STYLE_HINT_FRAMECHANGE in nsStyle*::MaxDifference.
For those nsStyle* that do not have nsChangeHint_NeutralChange in their
CalcDifference, we should be able to elimate nsChangeHint_NeutralChange from
their MaxDifference as well.
MozReview-Commit-ID: B3VJWt6gKoL
--HG--
extra : rebase_source : 7b568b680be4ea108b08cc565f1651ded70d357d
Replace NS_STYLE_HINT_FRAMECHANGE with nsChangeHint_ReconstructFrame in
nsStyle*::CalcDifference.
MozReview-Commit-ID: 85WPCyYolal
--HG--
extra : rebase_source : 3a5e247fe38e0b75d9ea1826ce5758b5a5862675
The comment for nsChangeHint_ReconstructFrame is out-of-date.
In RestyleManager::ProcessRestyledFrames, we actually ignore all of the other
hints if ReconstructFrame is set. The old version was written when
ReconstructFrame was listed last. So, update the comment.
MozReview-Commit-ID: 97wMrW6S6ID
--HG--
extra : rebase_source : f1556012073e088af96c2e389532f1ae04b165af
According to our coding style guide, we should always brace controlled
statements, even a single-line consequent of an if-else-statement. It avoids
dangling else bugs.
MozReview-Commit-ID: FT1AR5MqOGw
--HG--
extra : rebase_source : 111b4f70c83a59ee7dab8bf8adf60bc10916cc79
This patch stops the widget code from passing along touch-derived contextmenu
events straight from Windows to Gecko, and instead lets the APZ gesture
detection code handle it. This allows the contextmenu event to be prevented
according to web standards, e.g. if the touchstart event is cancelled.
This changes to browser.js will affect both Linux and Windows, but the behaviour
implemented is in line with native Windows touch behaviour. We may want to
add an alternate codepath for Linux to better simulate "native" Linux behavior,
if there is such a thing for touch-derived contextmenu.
MozReview-Commit-ID: 18qzK15ic8E
For B2G we had this "special" behaviour where a long-press that didn't trigger
a contextmenu or whose contextmenu event was cancelled would still trigger a
click event. No other browser does this, and so I think it doesn't make sense
for us to keep doing it either. It also makes it much harder to implement the
Windows-style contextmenu, where the contextmenu pops up when you *lift* your
finger after doing a long-press.
MozReview-Commit-ID: K7NmkNbjfqY
