This is the most immediate solution to the problem. This is how
automation ends up building things because it's cross-compiling and
cross-compiling falls back to the code path of that feature, and this
solves the immediate problem of builds not working out of the box.
The more long term fix would be to fix the coreaudio-sys crate to do the
right thing.
Differential Revision: https://phabricator.services.mozilla.com/D39447
--HG--
extra : moz-landing-system : lando
XPIState.getModTime() was setting a .changed property that nothing ever
looks at. It also sets lastModifiedTime which is used from about:addons
but built-in addons aren't visible there so there's no point setting it
for them.
Differential Revision: https://phabricator.services.mozilla.com/D39061
--HG--
extra : moz-landing-system : lando
This requires replacing inclusions of it with inclusions of more specific prefs
files.
The exception is that StaticPrefsAll.h, which is equivalent to StaticPrefs.h,
and is used in `Codegen.py` because doing something smarter is tricky and
suitable for a follow-up. As a result, any change to StaticPrefList.yaml will
still trigger recompilation of all the generated DOM bindings files, but that's
still a big improvement over trigger recompilation of every file that uses
static prefs.
Most of the changes in this commit are very boring. The only changes that are
not boring are modules/libpref/*, Codegen.py, and ServoBindings.toml.
Differential Revision: https://phabricator.services.mozilla.com/D39138
--HG--
extra : moz-landing-system : lando
This was an oversight in the checkin for bug 1461244. tfoot was duplicated due to a copy and paste error, thead was not mapped at all. It is now properly mapped, and the test adjusted accordingly.
Differential Revision: https://phabricator.services.mozilla.com/D39305
--HG--
extra : moz-landing-system : lando
Instead of generating a single `init/StaticPrefList.h`, we now generate:
- `init/StaticPrefListAll.h`;
- `StaticPrefsAll.h`;
- one `init/StaticPrefList_*.h` file for each pref group;
- one `StaticPrefs_*.h` file for each pref group.
`StaticPrefs.h` still exists -- it's equivalent to all the `StaticPrefs_*.h`
files combined -- so no `.cpp` files are changed by this commit. The next
commit will remove that file and replace inclusions of it with inclusions of
the new files.
The patch also adds checking of the type of the `do_not_use_directly` field.
Differential Revision: https://phabricator.services.mozilla.com/D39134
--HG--
extra : moz-landing-system : lando
For background information on what "cancel content JS" does, see bug 1493225.
Differential Revision: https://phabricator.services.mozilla.com/D38264
--HG--
extra : moz-landing-system : lando
Ran rustfmt on geckodriver to more effectively perform
a refactoring in the next patch
Differential Revision: https://phabricator.services.mozilla.com/D39307
--HG--
extra : moz-landing-system : lando
The fronts are destroyed when the toolbox closes and when a front is destroyed,
all its listeners are removed. So there is no real value in trying to unregister
them. On top of that, this destroy method is called by Inspector.destroy
and doesn't wait for its completion.
Differential Revision: https://phabricator.services.mozilla.com/D39302
--HG--
extra : moz-landing-system : lando
This code in ToolSidebar.destroy looks dead as there shouldn't be any sidebar
loaded in distinct iframes anymore. So we are not trying to call sidebars destroy
from here anymore. Instead, it is being done from Inspector.destroy, via the _panels
Map.
Differential Revision: https://phabricator.services.mozilla.com/D39301
--HG--
extra : moz-landing-system : lando
...rather than people running into peculiar crashes running their tests
because functions are pointing at the wrong thing.
It would be more robust to version-check `ld`, but I figure people
wanting to do local cross-language LTO builds is rare enough that
setting an environment variable and rerunning configure is not a huge
hardship.
Differential Revision: https://phabricator.services.mozilla.com/D36742
--HG--
extra : moz-landing-system : lando
We found there is a mp3 where the size is empty in its ID3 header, which makes mp3 parser think of that we haven't parsed the header yet, and then skip unnecessary bytes again and again.
We should use `Maybe` to know whether we finish parsing the size or not.
Differential Revision: https://phabricator.services.mozilla.com/D39252
--HG--
extra : moz-landing-system : lando
