Summary:
This moves the load of favicons into the content process. We use the same logic
for finding favicons (based on waiting until none have shown up for a short
time) but then load the favicon and convert it to a data uri which we then
dispatch to the parent process. Along the way this fixes asssociating the load
with the tab for WebExtension and devtools, fixes CSP usage for the load, fixes
expiry detection of the favicon and stops us from loading the same resource
twice.
This change also merges the prefs browser.chrome.site_icons and
browser.chrome.favicons leaving just the former controlling favicon loading. It
adds the pref browser.chrome.guess_favicon to allow disabling guessing where
a favicon might be located for a site (at <hostname>/favicon.ico). This is
mainly to allow disabling this in tests where those additional yet automatic
requests are uninteresting for the test.
There are multiple clean-ups that can follow this but this is a first step along
that path.
MozReview-Commit-ID: E0Cs59UnxaF
Reviewers: mak
Tags: #secure-revision
Bug #: 1453751
Differential Revision: https://phabricator.services.mozilla.com/D1672
Differential Revision: https://phabricator.services.mozilla.com/D1673
Differential Revision: https://phabricator.services.mozilla.com/D1674
Differential Revision: https://phabricator.services.mozilla.com/D1850
Differential Revision: https://phabricator.services.mozilla.com/D1869
--HG--
rename : browser/base/content/test/general/browser_bug408415.js => browser/base/content/test/favicons/browser_bug408415.js
rename : browser/base/content/test/general/browser_bug550565.js => browser/base/content/test/favicons/browser_bug550565.js
rename : browser/base/content/test/general/browser_favicon_change.js => browser/base/content/test/favicons/browser_favicon_change.js
rename : browser/base/content/test/general/browser_favicon_change_not_in_document.js => browser/base/content/test/favicons/browser_favicon_change_not_in_document.js
rename : browser/base/content/test/general/browser_subframe_favicons_not_used.js => browser/base/content/test/favicons/browser_subframe_favicons_not_used.js
rename : browser/base/content/test/general/file_bug970276_favicon1.ico => browser/base/content/test/favicons/file_bug970276_favicon1.ico
rename : browser/base/content/test/general/file_bug970276_favicon1.ico => browser/base/content/test/favicons/file_bug970276_favicon2.ico
rename : browser/base/content/test/general/file_bug970276_popup1.html => browser/base/content/test/favicons/file_bug970276_popup1.html
rename : browser/base/content/test/general/file_bug970276_popup2.html => browser/base/content/test/favicons/file_bug970276_popup2.html
rename : browser/base/content/test/general/file_favicon_change.html => browser/base/content/test/favicons/file_favicon_change.html
rename : browser/base/content/test/general/file_favicon_change_not_in_document.html => browser/base/content/test/favicons/file_favicon_change_not_in_document.html
rename : browser/base/content/test/general/file_bug970276_favicon1.ico => browser/base/content/test/favicons/file_generic_favicon.ico
rename : browser/base/content/test/general/file_with_favicon.html => browser/base/content/test/favicons/file_with_favicon.html
extra : rebase_source : 6372b2681a59d267f966e9fa2ca9a54e3ff0cea0
extra : intermediate-source : b11aa832c41ac5beef9065f804d11fb7c9887990
extra : source : 638eb8a41245f6d9932861afda21edd5e0b2618a
Currently, do-these-references-alias queries for Wasm global variable
accesses are handled incorrecty. We fail to identify the case where both
references are indirect (that is, imported) as possibly-aliasing. This can
lead to incorrect code generation in some pretty simple cases involving
globals, when compiling Wasm via IonMonkey.
This commit fixes that. It also adds clarifying comments to
MWasmLoadGlobalVar::congruentTo and MWasmLoadGlobalVar::valueHash pertaining
to equivalance-of-loaded-values assessments.
--HG--
extra : rebase_source : 3f77fa1fd0085ab1922b8eaf7cb2d9891bc6e390
Changes that are persisted to the Rule view trigger debounced events which may reflect an older value of the Font Editor.
This causes a visible jitter while dragging the sliders until the final value settles.
This patch makes the sliders rely on internal state while interactive while still accepting outside state after the user
is done dragging.
MozReview-Commit-ID: LCB00qpMPjC
--HG--
extra : rebase_source : be01df1978362ae4cf795e9ca9bb74866c1d4b4f
Still causes a refresh of the Font Editor at most once every 100ms after
the last "property-value-change" is dispatched. This is done in order
to account for Bug 1464340. Updating a font property may cause a
different font face to be used (ex Courier -> Courier Italic) and that
should be reflected in the Font Editor.
The Font Editor needs to react to "property-value-change" to:
- update its state as a result of manual property changes in the Rule view
- update its state for the used font as a result of property changes
originating from within itself (dragging sliders, selecting instances).
MozReview-Commit-ID: IubQK42NccM
--HG--
extra : rebase_source : 941ffbc5af68e5771e90c701b499cd0e7277047c
We cannot simply pass the status code using nsIWebSocketListener::OnServerClose because it's called only when the connection is established. Instead, I'm passing TLS failure from http channel to nsIWebSocketListener::OnStop where the correct status code is set.
As a tweak the wasm CG has decided to allow the special case where an i64 global is
created from JS with the default zero value, while we're waiting for BigInt and
more general i64 support. This amounts to removing the error we would otherwise
signal in this case.
--HG--
extra : rebase_source : 680e25f094ddf6339e2eacc7a7da2b197d5d1849
This only recognizes the new syntax and adds a minimal amount of testing for that.
A subsequent patch will do a massive renaming in the wasm module to change
CurrentMemory to MemSize and GrowMemory to MemGrow, and change all test cases.
A final patch will remove support for the old syntax.
Also include webgl2-deqp, which we would like to run eventually, but not yet.
MozReview-Commit-ID: FDWdu1J0end
--HG--
extra : rebase_source : a47d88cb2c5eb82e4dfaa9e58d76acbf0736d35d
This assertion was added by review comment of bug 1487945. Since mutation event
handler of this test case hides resizer, this case hits this assertion.
Although 4th parameter of SetAttr can control mutation event, if this event
isn't fired, another test case (layout/base/tests/test_bug558663.html) becomes
failure.
So we should move the assertion before setting resizer attribute.
Differential Revision: https://phabricator.services.mozilla.com/D1854
--HG--
extra : moz-landing-system : lando
For example, this can happen when choosing File menu -> new Tab.
Focus briefly returns to the document in the original tab, so we ask that document to restore focus.
The remote document then sends a focus event to the parent.
However, before the parent can process that event, focus has already moved to the address bar for the new tab.
With this check, we discover that focus is now in the chrome and thus avoid firing the event for the remote accessible.
MozReview-Commit-ID: 7k58dzREqZD
--HG--
extra : rebase_source : 070d3a6b5032bd6d4cd36fb054be04509bb0faae
The 'all' shorthand has shipped a long time ago, so this pref is not needed
anymore.
MozReview-Commit-ID: GND8qSVAfCG
--HG--
extra : rebase_source : 10708e749911fa95554ed423a5782db61df67cd0
Without this, accessibility reports the chrome:// URL of the page element as the label, which is ugly for screen reader users in particular.
MozReview-Commit-ID: AIInSb79YcN
--HG--
extra : rebase_source : d39f2bc627eeb521122dbbcbdc4699af3942ca23
