Bug 1438688 made it so that XPT information is compiled directly into
the binary instead of being shipped separately in interface
files. This means that manifests are no longer necessary for JS
components, which means the manifest check in emitter.py can be
removed.
That check is the only use of NO_JS_MANIFEST, so that can in turn be
removed entirely.
Differential Revision: https://phabricator.services.mozilla.com/D8885
--HG--
extra : moz-landing-system : lando
This addresses a related issue along the way: a build that results in running
configure would not update the value of self.config_environment (and therefore
self.substs) as seen from the build driver, so out of date values would have
been used.
The changes to Makefile.in and client.mk made exploit the assumption that by
he time anything in the Make build is running, config.status is up to date.
Users running "make" without the benefit of "mach" will need to manually run
configure when necessary in order to take this into account.
Differential Revision: https://phabricator.services.mozilla.com/D8473
--HG--
extra : moz-landing-system : lando
I verified that we can still copy from Firefox to an older version of Firefox without this patch.
LibreOffice also still works. Talking to some GTK people on IRC they are also happy about UTF-8 instead of wrongly declared UCS2.
Differential Revision: https://phabricator.services.mozilla.com/D8467
--HG--
extra : moz-landing-system : lando
All of the enum entries must have a FunctionHook object but GetFileAttributesW only gets one if MOZ_SANDBOX is defined. This aligns the #define behavior of the enum with the #define behavior of its usage in FunctionHook.
Differential Revision: https://phabricator.services.mozilla.com/D8745
--HG--
extra : moz-landing-system : lando
The size of the frameset on the emulator is smaller than I expected, so we can't
scroll the full range of SCROLL_Y even when we've zoomed in somewhat.
Because SCROLL_Y has a maximum of 400 and the scroll got truncated to 292, we
divide the number in half.
So we don't have to generate yet another hard-coded scroll string for this case,
we switch to generating them on the fly from the test data for the respective
sub test.
Differential Revision: https://phabricator.services.mozilla.com/D8894
--HG--
extra : moz-landing-system : lando
GLContextSymbols previously had a deleted default ctor to prevent accidentally leaving its members uninitialized, instead of zeroing with aggregate initialization.
Differential Revision: https://phabricator.services.mozilla.com/D8796
--HG--
extra : moz-landing-system : lando
Move MozLength and MaxLength into generics, and drop the manual implementation
of ToComputedValue.
Depends on D8290
Differential Revision: https://phabricator.services.mozilla.com/D8291
--HG--
extra : moz-landing-system : lando
In order to get the correct computed value of these keywords, we have to
make sure we store the correct computed values in sizing properties in
both inline axis and block axis.
-moz-max-content and -moz-min-content should behave as the property's
initial value in block axis. -moz-fit-content and -moz-available are not
supported in block axis, so we also treat them as initial values.
Differential Revision: https://phabricator.services.mozilla.com/D8290
--HG--
extra : moz-landing-system : lando
1. The patch from bug 1476710 was nonsense and had the same effect as simply
deleting that line, because the ChildFragmentManager is only of interest if
the TabHistoryFragment loaded further Fragments itself.
2. The issue at hand is that under some circumstances the TabHistoryFragment
will be trying to dismiss itself while its responsible FragmentManager is
already busy transacting some Fragment state changes. More precisely, the
fact that the Fragment is calling popBackStack*Immediately*, which isn't
allowed if the FragmentManager is already handling some other transaction.
3. The dismiss() calls in response to the onClick() handlers are unproblematic,
because they won't trigger any FragmentManager activity through any route
other than the dismiss() call itself.
4. The dismiss() calls in onPause() *are* problematic because the Fragment-
Manager will already be busy pausing the TabHistoryFragment, so triggering a
further synchronous transaction is not allowed (and originally caused
bug 1476710).
5. If the onPause() call happened because some external entity was attempting to
remove the fragment (either BrowserApp directly, or indirectly by forwarding
a back button press to the FragmentManager), then the Fragment trying to
additionally remove itself is unnecessary.
6. If the onPause() call happens because the containing activity itself is being
paused, then the Fragment being dismissed is the desired outcome (see
bug 1093209), however the Fragment won't be able to remove itself because
a) A synchronous transaction is illegal at that point in time.
b) An async transaction would be possible, but might not complete until after
onSaveInstanceState() had subsequently already been called, which again
would be illegal because of state loss.
c) An async transaction allowing state loss would succeed in any case, but
would mean that if BrowserApp was subsequently destroyed while in back-
ground and then later recreated from the savedInstanceState, the Tab-
HistoryFragment would be recreated as well, which is undesired.
7. Therefore, the only way to dismiss the TabHistoryFragment when the containing
activity is pausing is to synchronously dismiss the Fragment from inside the
activity, *before* the onPause() call is forwarded to the FragmentManager.
8. Calling dismiss() in response to onDestroy() is unnecessary, because the
Fragment is already irrevocably being removed as soon as we hit onPause().
9. Because it doesn't make sense to have multiple TabHistoryFragments active at
the same time, we also change the logic such that any attempt to show a new
TabHistoryFragment will now replace the previous fragment.
This is also useful in view of the fact that in order to close the Fragment,
BrowserApp retrieves it by calling findFragmentByTag(), which simply returns
the first matching Fragment, i.e. wouldn't properly handle things if we ever
accidentally ended up with multiple Fragment instances active at the same
time.
Differential Revision: https://phabricator.services.mozilla.com/D8680
--HG--
extra : moz-landing-system : lando
One method signature was introduced in API 19, and another, with
selectionMode was introduced in 21.
Differential Revision: https://phabricator.services.mozilla.com/D8788
--HG--
extra : moz-landing-system : lando
This patch introduces the interface with a stub implementation that does
nothing. Follow-up bugs will add platform-specific implementations.
Differential Revision: https://phabricator.services.mozilla.com/D8480
--HG--
extra : moz-landing-system : lando
`<input type=datetime>` was dropped from the spec many years ago,
and is not supported by the platform. To JS code, it looks like a
regular text input box.
With removed support for "datetime" inputs, we can also fix a bug in the
InputWidgetHelper. Due to the use of getAttribute, if the attribute
value was capitalized, then the special date/time picker UI would not be
shown. This is corrected by using the "type" property instead.
I verified on Android Nougat that all other input types (date,
datetime-local, week, month, time) still work as intended.
Depends on D8668
Differential Revision: https://phabricator.services.mozilla.com/D8666
--HG--
extra : moz-landing-system : lando
When a time input expects seconds, e.g. via `<input type=time step=1>`,
then the UI should show a way to input seconds.
On Nougat, `data:text/html,<input type=time step=1>`,
the UI used to show a clock to select hours and minutes.
As of this commit, three spinners are shown (HH mm ss),
and if 24-hour mode is disabled, four of them (HH mm ss AM).
Depends on D8667
Differential Revision: https://phabricator.services.mozilla.com/D8668
--HG--
extra : moz-landing-system : lando
The "seconds" field is now supported for type="datetime-local".
Examples, tested on Android Nougat (7.0):
```
No seconds because step is a whole minute:
data:text/html,<input type="datetime-local" step="60">
No seconds because datetime is not a supported type (it is treated like
input type=text by the DOM, but somehow a datepicker still appears):
data:text/html,<input type="datetime" step="0">
Seconds because step is a second:
data:text/html,<input type="datetime-local" step="1">
```
The UI looks only slightly different: After "HH mm" there is now a "ss"
spinner, optionally followed by AM/PM.
Differential Revision: https://phabricator.services.mozilla.com/D8667
--HG--
extra : moz-landing-system : lando
We'd like to be able to implement label features with a Custom Element, and we
don't want to run CE reactions inside of NAC.
Differential Revision: https://phabricator.services.mozilla.com/D8241
--HG--
extra : moz-landing-system : lando
This (large) file exists in the lalrpop-snap crate and should be part of
the vendoring of that crate. However it seems to have been accidentally
removed in bug 1497446. This patch adds it back by running
./mach vendor rust --build-peers-said-large-imports-were-ok
on a clean m-c tree.
Differential Revision: https://phabricator.services.mozilla.com/D8863
--HG--
extra : moz-landing-system : lando
This is to know if DAMP works without e10s shims.
MozReview-Commit-ID: 2IZGlenkuzb
Differential Revision: https://phabricator.services.mozilla.com/D8839
--HG--
extra : moz-landing-system : lando
