Re: Intent to unship: cross-context @@hasInstance in IDL interfaces

[Peter Van der Beken via dev-platform]

Note that for now code running with system principals still has the 
hasInstance hook, so instanceof will still return true there if the 
platform object and its interface's prototype object are from different 
realms. We do plan to align to the behaviour from the spec everywhere in 
the near future [1], but it involves fixing a lot of existing code/tests 
[2].


We added an isInstance() static function on interface objects as a way 
to do cross-realm branding checks a while back (only exposed in realms 
running with system principals) [3]. New code running with system 
principals that needs to do a cross-realm branding check should use for 
example 'Node.isInstance(foo)', as opposed to 'foo instanceof Node'.


Peter

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1695435
[2] 
https://treeherder.mozilla.org/jobs?repo=try=c256674824c991dd3891889f613641a1a34e70bf

[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1428531

On 04/03/2021 21:53, Kagami Rosylight wrote:

https://github.com/heycam/webidl/pull/356 removed custom hasInstance behavior 
in 2017, and the feature has only been shipped by Firefox.

Dropping the support means that JavaScript `instanceof` operator will return 
false when the contexts of the object and the constructor don't match, e.g. the 
object is from an iframe and the constructor is from the top window.

The change will initially be only on Nightly to make sure there won't be any 
significant breakages, and then will propagate to stable versions.

Tracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1360715
WPT: https://wpt.live/WebIDL/ecmascript-binding/has-instance.html
Relevant flag: dom.webidl.crosscontext_hasinstance.enabled



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Fission Newsletter #4

[Peter Van der Beken via dev-platform]

It's been two months since the last newsletter and there have been quite 
some accomplishments for Fission.


Fission Milestones M4, M4.1 and M5

Fission M4 milestone aimed to get Mochitests running and successfully 
passing with Fission enabled. https://arewefissionyet.com/m4/?original 
shows the fantastic progress that has been made on this goal. We 
completed our M4 milestone by successfully getting 90% of Mochitests to 
pass with Fission enabled, in just about a quarter.
The remaining tests to be fixed by the core Fission team are at a low 
enough point that we started working towards the next milestone too. 
This milestone was made possible because of the support we received from 
all Firefox teams. The remaining test failures have been moved to an 
additional milestone (M4.1), so that the teams responsible for those 
tests continue the drive towards 100% Fission coverage on Mochitests. 
https://arewefissionyet.com/m4/ shows the burndown graph for M4.1. Some 
failing tests depend on WindowContext (under construction) and have been 
identified as such and are not covered in M4/M4.1. To help us get to 
100%, take a look at the spreadsheet 
(https://docs.google.com/spreadsheets/d/1kjp32JTuB4axM3wKx0iIYL2Ado-HcyeBhoY-siGxYAs/)† 
that tracks the failures and help out where you can.


With M4 done and the remaining Mochitest fixing moved to M4.1, we’re 
also shifting the focus of the core Fission team to the M5 milestone. 
The goal of M5 is to make Fission-enabled builds be usable by developers 
and testers for dogfooding. We’ll be focusing on crashes and broken 
major functionality.


†: mozilla-internal document, public read-only mirror
 
also available.



DocumentChannel

With Fission, the process that initiates a URI load might not be the 
same as the one that needs to display the content. Even worse, we 
frequently don’t know what the final process will be until we’ve 
finished navigating any HTTP redirects.


To solve this, the originating docshell will now create a 
DocumentChannel, a protocol-agnostic placeholder channel, rather than a 
real network channel. DocumentChannel proxies the request into the 
parent process, where we can wait for all redirects and then make the 
right decision about where to deliver the final content. This lets us 
move a lot of logic for how to target a load out of the originating 
docshell, and into the parent process.


DocumentChannel is now enabled on Nightly for all protocols, with the 
Fission-specific process selection code disabled. We’re currently 
working to support handling content that needs to be downloaded directly 
in the parent.



Parent process owning Session History

Session History is the part of a web engine that supports functions like 
the back/forward buttons, the History menu item, etc. It contains the 
state information about the pages that were loaded in a particular 
window/tab, such as the active scroll position, filled-in form data, and 
more. In Gecko, the state is currently stored in the child processes 
where those pages were loaded. With Fission, we're changing the 
processes in which pages are loaded, so we need to also re-architect how 
Session History works.


During a browsing session, the user could have navigated to different 
origins within the same tab, and so the tab’s session history data might 
apply to pages loaded in different processes. At any given point in 
time, a page can also contain iframes with data from different origins, 
which in turn implies session history contains data for all the 
corresponding processes. In order to not leak cross-origin data, we need 
to move the session history data to the parent process. We've landed 
(behind a pref) a major piece of this re-architecting work in M4 that 
moves most of the session history data to the parent process, while 
keeping the same underlying API. Because the existing APIs allowed 
synchronous access to the data, we're now using synchronous IPC messages 
to get or set the data in the parent process. The next step for this 
project is to remove the synchronous IPC messages and will require a new 
set of APIs which are currently being designed.



- The Fission Team.


Previous newsletters:
#1 

#2 

#3 


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: Chrome-only WebIDL interfaces no longer require DOM peer review

[Peter Van der Beken via dev-platform]

On 09/03/2018 00:06, Kris Maglione wrote:
There are different costs to WebIDL and XPIDL bindings. WebIDL bindings 
have more cost in terms of compiled code size. XPIDL have greater costs 
in terms of performance and runtime memory.


It's not that simple. In terms of runtime memory for example, XPIDL also 
has *different* costs than WebIDL (which requires a nsWrapperCache and 
CC integration). Depending on usage those might be greater or smaller.


How much have DOM peers been focusing on preventing over-use, so far? 
Granted, most of the WebIDL bindings I've created to date have been to 
address measurable performance issues, but I've never had a reviewer 
suggest that I should be worried about over-use.


I've certainly started to worry about it recently. I know you focused on 
performance sensitive interfaces specifically in your message (and in 
your patches), but I worry that that message will get lost over time. We 
really need to emphasize that there's a difference in cost. And there 
are fundamental differences between the two models that cause that.


That said, we should continue looking into reducing the cost of WebIDL 
in terms of binary size (and we are).


Peter
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Still-supported cases of out-of-tree XPCOM code?

[Peter Van der Beken via dev-platform]

It might be because this is a legacy 'embedded WebExtension' addon 
signed by Mozilla. It doesn't get disabled in 57 because it's signed by 
Mozilla. But we really should just load the WebExtension instead of 
using the legacy addon code imho.


On 15/11/2017 10:04, Henri Sivonen wrote:
> I don't quite understand the breakage. It seems to relate not to
> nsIJSON itself but to how extension-side XPCOM JS imports WebIDL
> interfaces (TextDecoder and TextEncoder, specifically). Anyway, that's
> beside the point for the question.

BTW, I talked this over with Andrea, the theory right now is that some 
existing code was broken and it undefined TextDecoder and the removal 
patch for nsIJSON in ContextualIdentityService.jsm depended on TextDecoder.


Peter
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

nsWrapperCache::SetIsDOMBinding is no more

[Peter Van der Beken]

When implementing a class inheriting from nsWrapperCache and using DOM 
bindings it used to be the case that one needed to call 
SetIsDOMBinding() from the constructor. This is no longer necessary, and 
nsWrapperCache::SetIsDOMBinding has been removed.


We've added a private nsWrapperCache::SetIsNotDOMBinding, which is still 
called by a couple of whitelisted classes. This function is going away 
in the near future, and no calls to it should be added. If you think you 
need to add a call you should talk to me first.


The relevant bug is https://bugzilla.mozilla.org/show_bug.cgi?id=1078744.

Peter
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

DOM Bindings Meeting - Monday @ 12:30 PM PST

[Peter Van der Beken]

Our (somewhat) weekly DOM bindings meetings continue on Monday May
5th at 12:30 PM PDT.

Meeting details:

* Monday, May 5th, 2014, 12:30 PM PDT (3:30 PM EDT/9:30 PM CEST)
* Dial-in Info:
 - Vidyo room: Boris Zbarsky 
(https://v.mozilla.com/flex.html?roomdirect.htmlkey=DXThGJaiHtX3)

 - In office or soft phone: extension 92
 - US/INTL: 650-903-0800 or 650-215-1282 then extension 92
 - Toll-free: 800-707-2533 then password 369
 - Conference number 9235

http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014month=5day=5hour=19min=30sec=0p1=248p2=33p3=54p4=37p5=195p6=136p7=43p8=250p9=224
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: NS_New$THING vs. new $THING

[Peter Van der Beken]

On 08/10/12 04:14, Boris Zbarsky wrote:

On 10/7/12 4:13 PM, Ehsan Akhgari wrote:

Nice!  Can you please share some info on when you can avoid
inheriting from nsISupports and whether we can make the cycle
collector aware of such objects?


Basically, the rules are as follows:

1)  You need to either not need cycle collection (e.g. because you have
no wrapper cache and no strong ref members) or need to implement the
native CC stuff as Andrew described.

2)  Your class must not be the return value of any XPIDL interface,
since those go through xpconnect and xpconnect can only deal with
nsISupports stuff.  The good news is that you can't violate this rule
and still compile unless your patch involves reinterpret_cast to
nsIWhatever, which will hopefully get you a swift r-.  ;)


We'll also have to land the patches from 
https://bugzilla.mozilla.org/show_bug.cgi?id=799465 (I actually have a 
patch in that bug that removes nsISupports from an existing class).


Peter

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform