The pref dom.chrome_frame_access.enabled will default to true. When false, it will block various methods that chrome code can use to traverse subframes. The initial list is:
iframe.contentWindow
iframe.contentDocument
window.top
window.parent
window.opener
window.frames[i]
window.frames.length
MessageEvent.source
More blocks are likely to be added in the future.
Differential Revision: https://phabricator.services.mozilla.com/D13180
--HG--
extra : moz-landing-system : lando
This backs out the main patch landed earlier in bug 1194856 and the
patch from bug 1225004.
Differential Revision: https://phabricator.services.mozilla.com/D14050
--HG--
extra : moz-landing-system : lando
In particular, Zimbra apparently still relies on moz-prefixed gradients for
Firefox users, so let's avoid breaking Zimbra for beta users. I'm working on
getting Zimbra fixed so that this can eventually ride the trains, though,
barring other bustage that can't be addressed via outreach...
Added defines to mar_extract.c, mar_read.c, bsdiff.c so they use the ISO C and C++ conformant name.
Ran clang format on bspatch.cpp and the files under modules/libmar except for nss_secutil.c and nss_secutil.h since they are copies of nss code.
1. Set nsIPaymentRequest.completeStatus as 'updating' when calling
nsIPaymentRequestService::Change*. After event handling done, set
nsIPaymentRequest.completeStatus as '' and call
nsIPaymentUIService::UpdatePayment()
2. When the page handles PaymentRequestUpdateEvent or the Promise of
PaymentRequest::Show() over the dom.payments.response.timeout, set
nsIPaymentRequest.completeStatus as 'timeout' and call
PaymentUIService::UpdatePayment() automatically
3. Set nsIPaymentRequest.completeStatus as 'nohandler' when dispatching
PaymentRequestUpdateEvent and no event handler for it.
4. Set the initial valud of dom.payments.response.timeout to 20000 ms.
--HG--
extra : rebase_source : 7fe64a05bf7d20726c95aadd6e85bc14cb26bd3f
This is a best effort attempt at ensuring that the adverse impact of
reformatting the entire tree over the comments would be minimal. I've used a
combination of strategies including disabling of formatting, some manual
formatting and some changes to formatting to work around some clang-format
limitations.
Differential Revision: https://phabricator.services.mozilla.com/D13371
--HG--
extra : moz-landing-system : lando
In case anchor and area elements have target=_blank and no rel=opener/noopener,
this patch makes so that rel=noopener is implied. This feature is behind pref
'dom_targetBlankNoOpener_enabled'.
See: https://github.com/whatwg/html/issues/4078
In case anchor and area elements have target=_blank and no rel=opener/noopener,
this patch makes so that rel=noopener is implied. This feature is behind pref
'dom_targetBlankNoOpener_enabled'.
See: https://github.com/whatwg/html/issues/4078
Changes for nsIDOMWindowUtils.getOMTAValue is in the next commit with come test
cases.
Differential Revision: https://phabricator.services.mozilla.com/D13001
--HG--
extra : moz-landing-system : lando
Disallows files from referencing the same bytes in the content blocks of a MAR
file by storing a list of structs containing a file's byte offsets and lengths.
A list was chosen since the cap of 256 files wouldn't produce considerable
overhead when extracting/reading/searching/etc through the archive.
Removing the ability for a MAR file to reference the same content block
repeatedly seems like a better solution than what was suggested in the BLRG
report. (limiting the number of files or checking for overly large
decompressed files)
Allows us to prohibit this type of file bomb while only losing an attribute
of the MAR file format that wasn't being leveraged. The fix is applied in
mar_enum_items and mar_find_item so that the manifest the updater uses is
equally safeguarded as the mar host tool.
Differential Revision: https://phabricator.services.mozilla.com/D11706
--HG--
extra : moz-landing-system : lando
The usage of our specific "text" event is enough low (0.0003%). So, let's
stop dispatching the event in the default group of web content. Once we
release this new behavior, we can get rid of dispatching the event even in
chrome. Then, we can optimize the event order for new specs.
Differential Revision: https://phabricator.services.mozilla.com/D13034
--HG--
extra : moz-landing-system : lando
It seems that Google Docs have already been fixed their bugs of mirroring
keyCode and charCode values of our keypress events. Therefore, we should
remove docs.google.com from the blacklist and collect new feedback from
Nightly testers.
Differential Revision: https://phabricator.services.mozilla.com/D13035
--HG--
extra : moz-landing-system : lando
Changes for nsIDOMWindowUtils.getOMTAValue is in the next commit with come test
cases.
Differential Revision: https://phabricator.services.mozilla.com/D13001
--HG--
extra : moz-landing-system : lando
Simplify error handling in GLContext.
Modernize context loss handling in GLContext.
Remove various unused parts.
Fix WebGLContext's context loss/restoration.
MozReview-Commit-ID: Lu2hi5HnP8x
Differential Revision: https://phabricator.services.mozilla.com/D12496
--HG--
extra : moz-landing-system : lando
* Moves the value of the pref and also the fallback definition in nsTextToSubURI.cpp to a separate file.
* The file has better formatting, so we may follow its history more easily. Each range of consecutive values is defined on a separate line.
* Renames `blacklist` to `blocklist` for pref and variable names (for this individual pref. network.IDN.whitelist.* needs to be handled in a separate bug)
* Changes nsIDNService::mIDNBlocklist from being an nsString to sorted nsTArray<char16> and uses mozilla::BinarySearch() to check for characters.
Differential Revision: https://phabricator.services.mozilla.com/D12209
--HG--
extra : moz-landing-system : lando
On some Windows systems and many Android, those are hardware accelerated resulting is much lower CPU usage during calls.
Differential Revision: https://phabricator.services.mozilla.com/D12448
--HG--
extra : moz-landing-system : lando
All H264 system's decoders now handle low latency mode and are typically hardware accelerated.
We disable it for now on Android due to bug 1509316
Differential Revision: https://phabricator.services.mozilla.com/D12432
--HG--
extra : moz-landing-system : lando
Bug 1483553 was fixed by the developers of medium.com so that we can remove
medium.com from the blacklist which prevents strict keypress dispatching on
specific websites.
Differential Revision: https://phabricator.services.mozilla.com/D12398
--HG--
extra : moz-landing-system : lando
Also, fix a minor bug where when we discard an animated image that is a
full frame animated image, we need to reset
AnimationState::mCompositedFrameInvalid to false, just like we do for
animated images blended by FrameAnimator. This is because it is used as
part of our state checking in FrameAnimator::GetCompositedFrame before
we are willing to yield frame data.
Differential Revision: https://phabricator.services.mozilla.com/D12362
This improves performance by keeping snapshots around for some time if there are no changes done by other processes. If a snapshot is not destroyed immediately after getting into the stable state then there's a chance that it won't have to be synchronously created again when a new opeartion is requested.
There's now an upper limit for snapshot prefilling. The value is configurable and is currently set to 4096 bytes.
Snapshots can operate in multiple modes depending on if all items have been loaded or all keys have been received. This should provide the best performance for each specific state.
This patch also adds support for creating explicit snapshots which can be used for testing.
The implementation is based on a cache (datastore) living in the parent process and sync IPC calls initiated from content processes.
IPC communication is done using per principal/origin database actors which connect to the datastore.
The synchronous blocking of the main thread is done by creating a nested event target and spinning the event loop.
Summary:
Adds some missing braces on if structures
Adds a check for i being larger or equal to nb
Reviewers: rstrong
Reviewed By: rstrong
Bug #: 1468542
Differential Revision: https://phabricator.services.mozilla.com/D12193
--HG--
extra : rebase_source : 51a99f5376ed8877162e82b6c15f147df81981f8
This pref is left over from B2G days. It is currently disabled for firefox
desktop, but not for Android. This didn't affect us until now because we
always ran Android tests in non-e10s mode.
The pref ought to be removed in bug 1306801.
Differential Revision: https://phabricator.services.mozilla.com/D12293
--HG--
extra : moz-landing-system : lando
This patch removes the following functions:
* nsContentUtils::IsCustomElementsEnabled()
* CustomElementRegistry::IsCustomElementEnabled(JSContext* aCx, JSObject* aObject)
* CustomElementRegistry::IsCustomElementEnabled(nsIDocument* aDoc)
and all references of the pref.
Depends on D11183
Differential Revision: https://phabricator.services.mozilla.com/D11249
--HG--
extra : moz-landing-system : lando
This patch removes the dom.webcomponents.shadowdom.enabled pref and all its
references, including the following functions:
* nsContentUtils::IsShadowDOMEnabled()
* nsIDocument::IsShadowDOMEnabled()
* nsDocument::IsShadowDOMEnabled(JSContext* aCx, JSObject* aGlobal)
* nsDocument::IsShadowDOMEnabled(const nsINode* aNode)
* nsTextNode::IsShadowDOMEnabled(JSContext* aCx, JSObject* aObject)
This function is renamed and updated to nsDocument::IsCallerChromeOrAddon():
* nsDocument::IsShadowDOMEnabledAndCallerIsChromeOrAddon(JSContext* aCx, JSObject* aObject)
I didn't change the tests that load Shadow DOM tests in an iframe, in the interest of keeping hg annotation history.
Differential Revision: https://phabricator.services.mozilla.com/D11183
--HG--
extra : moz-landing-system : lando
This patch introduces 2 new prefs:
- devtools.console.stdout.chrome: if true, console API writes on stdout when
used by chrome code
- devtools.console.stdout.content: console API write on stdout when used by
content code.
This patch also takes the timeout for killing a content process back to its
original value and removes a related but long unused field.
Differential Revision: https://phabricator.services.mozilla.com/D11739
--HG--
extra : moz-landing-system : lando
This patch removes the following functions:
* nsContentUtils::IsCustomElementsEnabled()
* CustomElementRegistry::IsCustomElementEnabled(JSContext* aCx, JSObject* aObject)
* CustomElementRegistry::IsCustomElementEnabled(nsIDocument* aDoc)
and all references of the pref.
Depends on D11183
Differential Revision: https://phabricator.services.mozilla.com/D11249
--HG--
extra : moz-landing-system : lando
This patch removes the dom.webcomponents.shadowdom.enabled pref and all its
references, including the following functions:
* nsContentUtils::IsShadowDOMEnabled()
* nsIDocument::IsShadowDOMEnabled()
* nsDocument::IsShadowDOMEnabled(JSContext* aCx, JSObject* aGlobal)
* nsDocument::IsShadowDOMEnabled(const nsINode* aNode)
* nsTextNode::IsShadowDOMEnabled(JSContext* aCx, JSObject* aObject)
This function is renamed and updated to nsDocument::IsCallerChromeOrAddon():
* nsDocument::IsShadowDOMEnabledAndCallerIsChromeOrAddon(JSContext* aCx, JSObject* aObject)
I didn't change the tests that load Shadow DOM tests in an iframe, in the interest of keeping hg annotation history.
Differential Revision: https://phabricator.services.mozilla.com/D11183
--HG--
extra : moz-landing-system : lando
LocalStorage needs to be exposed in every context except for sandboxes and
NullPrincipals (data: URLs, for instance). But we need to keep data
separate in some scenarios: private-browsing and trackers.
In private-browsing, LocalStorage keeps data in memory, and it shares
StorageEvents just with other origins in the same private-browsing
environment.
For Trackers, we expose a partitioned LocalStorage, which doesn't share
data with other contexts, and it's just in memory. Partitioned localStorage
is available only for trackers listed in the
privacy.restrict3rdpartystorage.partitionedHosts pref. See
nsContentUtils::IsURIInPrefList to know the syntax for the pref value.
Now that h2 is pretty well stable, and we're fairly confident in our hpack table implementation, it's worth hiding this logging without some extra hoops, as it's just a lot of noise in logs.
Differential Revision: https://phabricator.services.mozilla.com/D11406
--HG--
extra : moz-landing-system : lando
This adds a button to the preferences UI to restore the default value for network.trr.uri preference.
Differential Revision: https://phabricator.services.mozilla.com/D11356
--HG--
extra : moz-landing-system : lando
We want to introduce a new pref to block trackers that try to workaround our
heuristic. The pref is called:
privacy.restrict3rdpartystorage.userInteractionRequiredForHosts
- modify line wrap up to 80 chars; (tw=80)
- modify size of tab to 2 chars everywhere; (sts=2, sw=2)
--HG--
extra : rebase_source : 7eedce0311b340c9a5a1265dc42d3121cc0f32a0
extra : amend_source : 9cb4ffdd5005f5c4c14172390dd00b04b2066cd7
First one is for bug 968056. UI Events declares that "keypress" events should
be dispatched only when a key press produces one or more characters (and also
discussing about Enter key press for backward compatibility). Therefore, we
should stop dispatching "keypress" events for non-printable keys (like arrow keys,
Ctrl + A, etc) in the default group on content for conforming to UI Events, but
keep dispatching them in chrome and in the system group on content.
Next one is for bug 1479964. No spec declares that what value should be set
to keyCode and charCode value of "keypress" events because declaring that would
break existing web apps which handle them with UA string. However, some web
apps assume that if window.event is available, keyCode value of "keypress" event
is set to a Unicode code point of inputting character. We set only charCode
to it, but the other browsers sets both keyCode and charCode to a Unicode
code point of inputting character. Therefore, we need to follow the other
browsers' behavior for this because changing value from zero to non-zero is
safer than non-zero to non-zero or zero.
And also next one is for bug 354358. UI Events declares that "keydown" and
"keyup" events represent physical key state and should be fired even during
composition. As far as the reported issues, this behavior is expected mainly
by Korean web developers and some web apps depend on the behavior. Therefore,
we need to start to dispatch them during composition.
Finally, for bug 218415, we should enable window.event. This is declared by
the Living DOM Standard. A lot of web apps depend on window.event and the
last blocker, bug 1479964 was fixed so that it is the time to enable this.
Differential Revision: https://phabricator.services.mozilla.com/D13376
--HG--
extra : moz-landing-system : lando
Basically, we shouldn't have blacklist to disable web API. However, the
keypress event behavior changes are not standardized things. Therefore,
if some web developers realize that they need to change their apps when
it's too late for them, Firefox users need to use another browser for
such web apps for several weeks or more, and such things may make the users
switch their default browser. For avoiding such worst scenario, we should
take the blacklists and if we get such compatibility reports, we should
add the domains into the blacklist even in release channel.
Differential Revision: https://phabricator.services.mozilla.com/D13374
--HG--
extra : moz-landing-system : lando
Remember The Milk have upgraded their Google Closure Library and the bug has
gone now. Let's remove www.rememberthemilk.com from the blacklist.
Differential Revision: https://phabricator.services.mozilla.com/D13373
--HG--
extra : moz-landing-system : lando
