This was added in Firefox 38 and isn't used anywhere
in the codebase. Let's remove it.
Differential Revision: https://phabricator.services.mozilla.com/D40544
--HG--
extra : moz-landing-system : lando
This patch introduces a new Rust crate called `static_prefs`.
It also changes generate_static_pref_list.py to generate two new files.
- StaticPrefsCGetters.cpp: contains C getters, which are just wrappers around
the C++ getters. This is included into Preferences.cpp.
- static_prefs.rs: contains declarations for the C getters, plus the `pref!`
macro which provides nice syntax for calling the C getters. This is included
into static_prefs/src/lib.rs.
The new code is only generated for prefs marked with the new `rust` field in
the YAML. It's opt-in because there's no point generating additional code for
900+ static prefs when only about 20 are currently used from Rust.
This patch only marks a single pref (`browser.display.document_color_use`) with
`rust: true`. That pref isn't accessed from Rust code in this patch, but it's
necessary because the generated Rust code is invalid if there are zero
Rust-accessed prefs. (The next patch will access that pref and others from Rust
code.
Differential Revision: https://phabricator.services.mozilla.com/D40791
--HG--
extra : moz-landing-system : lando
generate_static_pref_list currently has two functions:
- generate_header(): this checks the YAML and generates most of the code.
- emit_header(): this does a bit of additional code generation and writes the
code to file.
This patch gives it a cleaner structure:
- check_pref_list(): this checks the YAML.
- generate_code(): this generates all the code. (It calls check_pref_list()
first.)
- emit_code(): this just writes the code to file.
The patch also improves the testing in test_generate_static_pref_list.py,
so that it checks the full contents of all generated files.
All these improvements will help with the next patch, which adds two additional
generated files.
The patch also fixes a couple of minor errors in the comment at the top of
StaticPrefList.yaml.
Differential Revision: https://phabricator.services.mozilla.com/D40790
--HG--
extra : moz-landing-system : lando
Remove unnecessary key values, replace componentWillReceiveProps, did some cleanup
Differential Revision: https://phabricator.services.mozilla.com/D39706
--HG--
extra : moz-landing-system : lando
It makes little sense to copy a writer (also an output iterator).
We're keeping it move-constructible (so it can be passed around for construction
purposes), but not move-assignable to help make more members `const`.
Differential Revision: https://phabricator.services.mozilla.com/D40622
--HG--
extra : moz-landing-system : lando
This makes it easier to grab all BlocksRingBuffer state variables:
- Range start and end.
- Number of pushed blocks/entries, number of cleared blocks/entries.
The function is thread-safe, and the returned values are consistent with each
other, but they may become stale straight after the function returns (and the
lock is released).
They are still valuable to statistics, and to know how far the range has at
least reached (but may go further soon).
Differential Revision: https://phabricator.services.mozilla.com/D40621
--HG--
extra : moz-landing-system : lando
Renamed `BPAutoLock` to `BaseProfilerAutoLock`.
DEBUG-build `~BaseProfilerMutex()` checks that it is unlocked.
Prevent `BaseProfilerMutex` and `BaseProfilerAutoLock` copies&moves.
DEBUG-build check that `Lock()` sees `mOwningThreadId`==0 (because that is the
initial value, and the value after a previous `Unlock()`).
Don't preserve atomic `mOwningThreadId` in JS recording.
Differential Revision: https://phabricator.services.mozilla.com/D40620
--HG--
extra : moz-landing-system : lando
`ProfilerMarkerPayload::Set...()` functions are only used by derived classes in
the same files, and these values could just be set during construction.
Differential Revision: https://phabricator.services.mozilla.com/D40619
--HG--
extra : moz-landing-system : lando
This fixes an edge case where it was possible for an HTMLMediaElement in the
middle of setup to have ownership transferred to a inactive document and deref a
null pointer. This happened because we have special handling for EME related
media where we perform more aggressive shutdown on for media in inactive
documents.
As far as I can tell, there's nothing specced that forbids performing EME
related functionality on elements in inactive documents. However, our code
already prevents doing so in other cases. E.g. if you create an inactive
document, place an HTMLMediaElement in it and try to setup EME related data on
it, then that will fail. So this fix just covers another such case.
While it would be nice to support doing these operations on inactive document's
media, it seems like very much an edge case, and something that would require a
large amount of reworking in how we handle inactive documents. We can cross that
bridge later should we ever need do so.
Differential Revision: https://phabricator.services.mozilla.com/D40482
--HG--
extra : moz-landing-system : lando
I have landed bug 1527796 to support artifact build on Windows, but after bug 1515248 is landed, it is broken again. Path separator on Windows is '\', not '/'. So we should use leaf name instead.
Differential Revision: https://phabricator.services.mozilla.com/D40758
--HG--
extra : moz-landing-system : lando
Before this change, the bookmarks mirror used a cloned Places
connection for reads and writes. This avoided interleaving writes from
Sync and other Places consumers, where `mozStorageTransaction` or
`Sqlite.jsm` would see that a transaction was already in progress, and
execute statements as part of that transaction.
However, using a separate connection caused write contention, wedging
the main connection in an infinite `SQLITE_BUSY` retry loop. This
blocked all writes to Places until shutdown, at which point we'd hang
waiting to shut down the async thread. Bug 1435446 reduced this, but
didn't eliminate the hangs entirely.
Since the mirror first landed, we've made three changes, to the point
that using the main connection is feasible now:
1. Merging and application happen in Rust. This means we run everything
on the async thread, so no other async statements can run during
merging.
2. Most uses of the synchronous bookmarks API have been removed. The
only remaining caller is the tagging service, and we never sync the
tags root.
3. We only update parents and positions for items that actually changed,
instead of walking the entire tree.
To that end, this commit removes the cloned connection, and uses the
main Places connection directly.
Differential Revision: https://phabricator.services.mozilla.com/D39890
--HG--
extra : moz-landing-system : lando
This commit reduces the number of database writes and table scans
needed to merge synced bookmarks.
* Remove `fetchNew{Local, Remote}Contents`. Fetching the tree already
scans the table, so we can piggyback on it to fetch content info for
deduping.
* Store completion ops in temp tables to only update changed parts of
the local tree, and remove the `mergeStates` table and views.
* Replace the `itemsToMerge` view with an indexed `itemsToApply` temp
table.
* Replace the `updateGuidsAndSyncFlags` trigger with a `changeGuidOps`
table and a `changeGuids` trigger.
* Replace the `updateLocalItems` trigger with an `apply_remote_items`
function to bulk upsert new and updated items.
* Replace the `structureToMerge` view with an
`applyNewLocalStructureOps` table that holds parents and positions
for moved items, and an `applyNewLocalStructure` trigger to update
them.
* Remove tombstones for revived items, update change counters, and flag
mirror items as merged directly in `update_local_items_in_places`,
instead of indirecting through temp tables.
* Don't mark items flagged for reupload as merged, since we'll write
them back to the mirror after upload.
* Use a scalar subquery instead of a join in the `localTags` view to
look up the tags root ID.
* Replace `relatedIdsToReupload` with a `Store::prepare` method that
flags all bookmarks with keyword-URL mismatches for reupload.
* Trigger frecency updates for origins once, not for every item.
* Remove two extra scans on `itemsAdded` and `itemsChanged` when
recording observer notifications for changed keywords.
* Notify all `bookmark-added` listeners in a single batch.
This also fixes some edge cases:
* Update root positions correctly after deleting a non-syncable root
or item.
* Keyword-URL mismatches may reupload more items than before, but now
ensure that all bookmarks with the same URL have the same keyword.
* Only set items with deduped GUIDs to `SYNC_STATUS_NORMAL` after
merging.
* Bump the last modified time for modified items only.
Differential Revision: https://phabricator.services.mozilla.com/D39889
--HG--
extra : moz-landing-system : lando
The new StaticLocalAutoPtr smart pointer has a trivial destructor, so we will
either properly clean up this data or leak it on process shutdown. Either way,
we will not destroy it in a way that the underlying type does not support.
Differential Revision: https://phabricator.services.mozilla.com/D40842
--HG--
extra : moz-landing-system : lando
This patch implements how to use MediaController to control corresponding media in content processes.
Differential Revision: https://phabricator.services.mozilla.com/D38145
--HG--
extra : moz-landing-system : lando
We implement some helpful functions in MediaControlUtils which can be used to notify controller when media starts/stops playing or become audible/inaudible.
For now, we can temporarily notify these changes in AudioChannelService where we have already known when media has these kinds of status changing.
Differential Revision: https://phabricator.services.mozilla.com/D38144
--HG--
extra : moz-landing-system : lando
We don't want to enable audio competing by default, so hide this feature behind a static pref.
Differential Revision: https://phabricator.services.mozilla.com/D38143
--HG--
extra : moz-landing-system : lando
In order to support audio competing among different tabs, we implement a new class AudioFocusManager.
AudioFocusManager is used to assign the audio focus to different requester and decide which requester can own audio focus when audio competing happens.
When the audio competing happens, the last request would be a winner who can still own the audio focus, and all the other requesters would lose the audio focus.
Now MediaController is the onlt requester, it would request the audio focus when it becomes audible and revoke the audio focus when the controller is no longer active.
Differential Revision: https://phabricator.services.mozilla.com/D38142
--HG--
extra : moz-landing-system : lando
In order to have a centralized audio control in the parent process, we create two new classes here.
* MediaController
MediaController is a class used to control certain amount of media in the content process. Every controller corresponds to a browsing context.
For example, TabMediaController would correspond to the top level browsing context, which mean it can control all media in the specific tab.
* MediaControlService
As there might be multiple tabs playing audio, so there would be multiple controllers. MediaControlService is a place to manage all of them, you can access specific controller through MediaControlService by providing controller ID.
Everytime a controller becomes active, which means there is a media starts in corresponding browsing context, then controller would be added into the list of the MediaControlService. And it would be removed from the list when the media in corresponding browsering context stopped.
Differential Revision: https://phabricator.services.mozilla.com/D38141
--HG--
extra : moz-landing-system : lando
This makes eager processing the default as well, which makes the code
effectively work how it does before the FunctionTree patches.
Differential Revision: https://phabricator.services.mozilla.com/D40480
--HG--
extra : moz-landing-system : lando
While here, properly export StackWalk.h when building with
--enable-project=memory.
Differential Revision: https://phabricator.services.mozilla.com/D40731
--HG--
extra : moz-landing-system : lando
