The former is broken because of a lack of a app.mozbuild file and has
been broken for years.
The latter doesn't do anything useful outside --enable-project=extensions
because all the subdirectories of extensions/ are already covered by
other flags (or always used):
- auth, via --enable-negotiateauth (default on)
- permissions, always
- pref, via --enable-pref-extensions (default on)
- spellcheck, always
- universalchardet, via --enable-universalchardet (default on)
Also, nothing sets MOZ_EXTENSIONS_DEFAULT anymore.
Differential Revision: https://phabricator.services.mozilla.com/D133970
The former is broken because of a lack of a app.mozbuild file and has
been broken for years.
The latter doesn't do anything useful outside --enable-project=extensions
because all the subdirectories of extensions/ are already covered by
other flags (or always used):
- auth, via --enable-negotiateauth (default on)
- permissions, always
- pref, via --enable-pref-extensions (default on)
- spellcheck, always
- universalchardet, via --enable-universalchardet (default on)
Also, nothing sets MOZ_EXTENSIONS_DEFAULT anymore.
Differential Revision: https://phabricator.services.mozilla.com/D133970
It has two methods which take (signed) `long` argument to specify offset in a
DOM node, but it's declared as "unsigned long" in the standards. And now,
they work with rewritten Selection API which take `uint32_t` so that they should
use `unsigned long` for making the handling simpler and safer.
Differential Revision: https://phabricator.services.mozilla.com/D131034
It's an internal API corresponding to `Selection.getRangeAt` DOM API.
I think that it should use `uint32_t` rather than `size_t` because of the
consistency with the DOM API and `Selection::RangeCount()`.
This patch fixes all callers of `GetRangeAt()`, and rewrites it with ranged-
loops unless original ones do not refer `RangeCount()` every time and may run
script in the loop.
Differential Revision: https://phabricator.services.mozilla.com/D128848
This reduces the number of wasm pages allocated from 64 to 47 on en_us
builds, corresponding to about 1 MB of reduced memory usage.
There are a few methods on HashMgr that can transfer buffers to external
consumers — namely decode_flags and encode_flag. Because the former is
also called by internal consumers, we need to be careful to
conditionally use the arena for only the internal consumers.
Differential Revision: https://phabricator.services.mozilla.com/D132519
This reduces the number of wasm pages allocated from 64 to 47 on en_us
builds, corresponding to about 1 MB of reduced memory usage.
Differential Revision: https://phabricator.services.mozilla.com/D132519
-Wshadow warnings are not enabled globally, so these -Wno-shadow suppressions have no effect. I had intended to enable -Wshadow globally along with these suppressions in some directories (in bug 1272513), but that was blocked by other issues.
There are too many -Wshadow warnings (now over 2000) to realistically fix them all. We should remove all these unnecessary -Wno-shadow flags cluttering many moz.build files.
Differential Revision: https://phabricator.services.mozilla.com/D132289
- Increment permissions database schema version
- Apply GetSite to origin keys with type prefixed by "3rdPartyStorage^"
- Done in a transaction
- Add unit test for migration
Differential Revision: https://phabricator.services.mozilla.com/D130676
- Adding browser tests to verify correct behavior in integration
- New test that fails on previous version: toolkit/components/antitracking/test/browser/browser_storageAccessScopeSameSiteWrite.js
- Add the ability to store permission by site, use 3rdPartyStorage for this
- No change is made to permission reads. These already proceed recursively, which eventually reach the site.
- When fetching all permissions for a principal, also look for site-scoped permissions on its site's principal
Differential Revision: https://phabricator.services.mozilla.com/D130675
- Increment permissions database schema version
- Apply GetSite to origin keys with type prefixed by "3rdPartyStorage^"
- Done in a transaction
- Add unit test for migration
Differential Revision: https://phabricator.services.mozilla.com/D130676
- Adding browser tests to verify correct behavior in integration
- New test that fails on previous version: toolkit/components/antitracking/test/browser/browser_storageAccessScopeSameSiteWrite.js
- Add the ability to store permission by site, use 3rdPartyStorage for this
- No change is made to permission reads. These already proceed recursively, which eventually reach the site.
- When fetching all permissions for a principal, also look for site-scoped permissions on its site's principal
Differential Revision: https://phabricator.services.mozilla.com/D130675
`nsTextFragment` is a storage of data node and DOM offset is `uint32_t`, but
some methods of `nsTextFragment` takes `int32_t` for the offset/length in
its text. Therefore, callers need to cast from `uint32_t` to `int32_t` if
the offset value is offset in a DOM node. Therefore, all methods of it should
take `uint32_t` values as offset/length in its text.
Differential Revision: https://phabricator.services.mozilla.com/D127923
By default nsIPermissionManager will not persist data in private browsing.
There are cases however, like private-only-browser Firefox Focus, where we
would want to be able to persist tracking protection exceptions permanently.
This patch adds a new method called
`addFromPrincipalAndPersistInPrivateBrowsing` which allows setting permanent
permissions in private browsing..
Differential Revision: https://phabricator.services.mozilla.com/D126544
extensions/permissions/PermissionManager.cpp:2468:12: error: 'return' will never be executed [-Werror,-Wunreachable-code-return]
return NS_OK;
^~~~~
Differential Revision: https://phabricator.services.mozilla.com/D126875