We're currently fairly vague and inconsistent about the values we provide to
content policy implementations for requestOrigin and requestPrincipal. In some
cases they're the triggering principal, sometimes the loading principal,
sometimes the channel principal.
Our existing content policy implementations which require or expect a loading
principal currently retrieve it from the context node. Since no current
callers require the principal to be the loading principal, and some already
expect it to be the triggering principal (which there's currently no other way
to retrieve), I chose to pass the triggering principal whenever possible, but
use the loading principal to determine the origin URL.
As a follow-up, I'd like to change the nsIContentPolicy interface to
explicitly receive loading and triggering principals, or possibly just
LoadInfo instances, rather than poorly-defined request
origin/principal/context args. But since that may cause trouble for
comm-central, I'd rather not do it as part of this bug.
MozReview-Commit-ID: LqD9GxdzMte
--HG--
extra : rebase_source : 41ce439912ae7b895e0a3b0e660fa6ba571eb50f
This patch changes ClientID.jsm to only check for the pref validity if
the cached client id pref was set.
MozReview-Commit-ID: KI3YHaMozl6
--HG--
extra : rebase_source : 14d7c2408a16d21911c10112465c2afe590c85fb
What happens is the following:
- browser-child.js sends a statechange up to RemoteWebProgress.jsm that contains
a `documentContentType` value of `null`, along with `requestURI` and `originalRequestURI`
_after_ other state changes that did send a valid content-type.
- The content-type is used by the WebProgressListener in browser.js to toggle the
disabled state of the 'isImage' broadcaster.
- The 'isImage' broadcaster is used by the 'cmd_find' and 'cmd_findAgain' commands to
determine whether they should be enabled. In this case: not.
The fix here is to _not_ set the documentContentType in the browser binding when
it's `null`.
MozReview-Commit-ID: IELoCrnOH0j
--HG--
extra : rebase_source : 51211b7aee13eabc71f91e73df4fc6d69e5c624b
This applies the following changes:
- store a weak reference to the browser element in the WebNavigation.jsm Manager's map
of pending CreatedNavigationTarget messages
- when a CreatedNavigationTarget message is received from a sourceTab
for a created window that is not currently tracked in the map
(e.g. it has been immediately closed), the message received from the sourceTab
is not saved in the map of the pending CreatedNavigationTarget (and a message
is logged in the console to make easier to investigate issues related to discarded
CreatedNavigationTarget events).
- adds an additional assertion to the related test case to ensure that no CreatedNavigationTarget
message is still pending in the WebNavigation/jsm's Manager.
MozReview-Commit-ID: FijQ8IqiY8L
--HG--
extra : rebase_source : 20e5c27ba18f7f05f9076db19091f1c1153a6c39
This changes fixes the regression introduced by Bug 1355120 and adds a new
test case which contains a browserAction popup which open and immediately
close a new window and ensure that the received onCreatedNavigationTarget
is the expected one.
MozReview-Commit-ID: JIcVCpBTpxj
--HG--
extra : rebase_source : 0966eba7c752068522400b032a8018b96e9dcda9
We got rid of drawing lwthemes inside the titlebar on OSX in bug 1392219 but
there was still some code that adjusted the titlebar, which we forgot
remove. Incidentally, that code was also causing a bug (even before we
removed the in-titlebar drawing) which we now don't need to worry about
anymore now.
MozReview-Commit-ID: 44HR25Uyp8B
--HG--
extra : rebase_source : 12a9d427a021d00553be8949dd5f9fa7e37eef47
Moving the event type lists to constants avoids array construction overhead
for each event, and allows us to use the much faster Set.has rather than
Array.includes.
Using Object.create to add the base request info to the listener-specific info
allows us to avoid object copy overhead.
Switching to a .forEach() loop lets us avoid creating expensive live Map
iterator objects, and also GC pressure caused by the huge number of iterator
result objects and intermediate array objects created by for-of-entries().
It's otherwise just as fast as for-of in Ion.
MozReview-Commit-ID: 53Fw1tJbuMY
--HG--
extra : rebase_source : 7fd7095239fec790347d3febb8bf9af17fffc1af
We don't use the initial Map returned by ChannelWrapper as a map, so there's no
need for the overhead involved in creating it. We also don't need the header map
generated by HeaderChanger unless headers are actually being modified, which
for many listeners they never are, so there's no need for the map creation and
string lower-casing overhead prior to modification time.
MozReview-Commit-ID: K2uK93Oo542
--HG--
extra : rebase_source : f50574fb0eb32878aee3f68b3a73d46ba53987e5
This allows us to reuse the same URLInfo objects for each permission or
extension that we match, and also avoids a lot of XPConnect overhead we wind
up incurring when we access URI objects from the JS side.
MozReview-Commit-ID: GqgVRjQ3wYQ
--HG--
extra : rebase_source : 71c19fd8b432c16a3f13f7d0bd0424064f3e5661
The URL can end up being user-visible for "Recently closed tabs" (certainly on Android, and also when hovering over an entry on Desktop, at least in the old menu bar), so we should use pretty URLs instead of Punycode.
MozReview-Commit-ID: Kil2ChToYa8
--HG--
extra : rebase_source : 937332a852c6814317cdc58473437e3bc77faf15
We allow doorhangers to optionally disable the blue button
highlight for their main actions, but didn't account for the
fact that we display a default "OK" button when no mainAction
was provided.
MozReview-Commit-ID: 6ndWju3ytyq
--HG--
extra : rebase_source : 7ff7f85ed7cd538a1b499bf51e4cb11594a83a42
Dan Banner
Sebastian Hengst
Phil Ringnalda
Mike de Boer
Felipe Gomes
Kris Maglione
Alessio Placitelli
Shane Caraveo
Luca Greco
Peter Van der Beken
Georg Fritzsche
Robert Strong
Dão Gottwald
Johann Hofmann
Wes Kocher
Ryan VanderMeulen
Scott Wu
Andrea Marchesini
Kershaw Chang
Jan Henning
Ed Lee
Kit Cambridge
Jonathan Kingston
Tim Nguyen