Re: Intent to experiment: Web Share API

[Michael de Boer]

Dale Harvey implemented native share functionality on Desktop before, which you 
can access through the meatball menu, inside the urlbar.
So if you’d like to go for parity across platforms, please feel free to reach 
out.

Best,

Mike.

> On 1 Jul 2019, at 03:22, mcace...@mozilla.com wrote:
> 
> Summary: Experiment with Web Share API to figure out if the current spec is 
> implementable in Gecko/GeckoView. The specification defines an API for 
> sharing text, links and other content to an arbitrary destination of the 
> user's choice. The available share targets are either OS specific, or can be 
> other websites that are registered as "Share Targets". Web-based Share 
> Targets are not in scope right now - that's a different spec [1].
> 
> Bug: 
>  DOM side - https://bugzilla.mozilla.org/show_bug.cgi?id=1312422
>  Android side - https://bugzilla.mozilla.org/show_bug.cgi?id=1402369
> 
> Link to Standards: https://wicg.github.io/web-share/
> (This spec is migrating to the W3C's Web Platform WG in the next few weeks).
> 
> Platform coverage: Initially, Android (Fenix).
> 
> Estimated or target release: N/A 
> 
> Preference behind which this will be implemented: dom.share
> 
> Is this feature enabled by default in sandboxed iframes? no
> 
> DevTools bug: N/A 
> 
> Do other browser engines implement this?: Yes, WebKit, Blink. Shipping in 
> Chrome for Android and Safari on both iOS and Desktop.
> 
> web-platform-tests:  
> https://github.com/web-platform-tests/wpt/tree/master/web-share
> 
> Is this feature restricted to secure contexts? Yes
> 
> 
> [1] https://wicg.github.io/web-share-target/
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

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

Re: PSA: New method for registering XPCOM components

[Michael de Boer]

Hi Kris,

That looks really neat and a nice step forward! I’m a fan of all the things 
you’re doing, btw ;-)

Whilst reading through the docs you pointed at, I was missing a few things, to 
be honest:

* Perhaps a link (or multiple links) to MDN docs we already have on XPCOM 
components - which may provide an introduction as to what they are, when and 
why they’re used, etc.
* An example of ‘old style’ vs. ’new style’ xpcom definition, perhaps even a 
‘good’ vs. ‘bad’ - but there’s a negative connotation there, which may not be 
preferred.
* A full example (prolly on a second page would be best), which showcases the 
discrete steps to get from zero to hero. Err, I mean new component.

I’m suggesting all this extra work, because I think it will actually save you a 
lot in the future; rtfm is a very simple, yet powerful response to all the 
queries you’re gonna get.

Cheers,

Mike.

> On 5 Feb 2019, at 22:12, Kris Maglione  wrote:
> 
> As of bug 1478124, the new preferred method for registering XPCOM components 
> is via static manifest files, as documented here:
> 
> https://firefox-source-docs.mozilla.org/build/buildsystem/defining-xpcom-components.html
> 
> And, as of bug 1524688, it will be the preferred method of defining 
> JavaScript components as well as native ones.
> 
> The primary motivation for this change is to decrease the amount of memory 
> (and, to a lesser extent, startup performance) overhead that component 
> registrations consume in content processes, which would not have been 
> acceptable in the post-Fission world. It has the side-benefit, though, of 
> making most registrations much more straightforward, requiring only a single 
> entry, in a single place, for each component.
> 
> 
> Thank you to all of the reviewers who had to review a lot of very large 
> patches to make this possible, particularly Nathan Froyd, Eric Rahm, and Mike 
> Conley, on whom I dumped most of the biggest chunks.
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev

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

Re: Intent to implement: Visual Viewport API

[Michael de Boer]

> On 24 Jul 2018, at 01:36, Tanushree Podder  wrote:
> 
> Summary: Mobile web pages contain two viewports, the layout viewport and
> the visual viewport. The layout viewport consists of all the page contents
> and is specified by the meta-viewport tag. The visual viewport is the
> actual visible portion of the page on the screen excluding on-screen
> keyboards, areas outside of a pinch-zoom area or any other on-screen
> artifact that does not scale with the dimensions of the page. The purpose
> of the Visual Viewport API is to allow web developers to explicitly query
> the properties of the visual viewport.
> 
> Web developers can use this API in situations where they need to position
> web page elements to remain visible on the screen regardless of the visible
> portion of the web page. For example, if an image needs to be visible
> regardless of the pinch-zoom level of the device, it can be positioned
> relative to what’s shown on the screen using methods of the Visual Viewport
> API.

About the desktop perspective: is pinch-to-zoom a completely separate thing 
from full-page-zoom as can be controlled right now with Ctrl+ and Ctrl- using 
the
keyboard?
If that’s the case, I can see synchronization issues between the two features 
when they’re both in use.
My perception is that pinch-to-zoom is really full-page-zoom, but using the 
pointer coordinates as focal point instead of [0,0] and step-less zooming 
behaviour, instead of clamping to predefined steps.
If that’s not the case, I’d say the new API seems usable on desktop already 
once the page has been zoomed in.

Thanks,

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

Re: Intent to remove: do_check_*, do_print, do_execute_soon, do_register_cleanup

[Michael de Boer]

<3 Thanks so much for taking this, Florian!

> On 19 Dec 2017, at 20:14, Florian Quèze  wrote:
> 
> In order to reduce the confusion for people writing tests using both
> xpcshell and mochitests, I'm currently working on removing the old
> do_* helpers that have an obvious nicer equivalent.
> 
> This is happening in https://bugzilla.mozilla.org/show_bug.cgi?id=1421992
> 
> I'm removing the following do_check_* functions and replacing them
> with equivalent Assert.* calls in the existing xpcshell tests:
> do_check_true, do_check_false, do_check_eq, do_check_neq,
> do_check_null, do_check_matches.
> 
> Additionally, I'm renaming do_print to info, do_register_cleanup to
> registerCleanupFunction and do_execute_soon to executeSoon.
> 
> The patches are large (about 2000 files and 25000 lines touched) so
> I'm giving a heads up that I'm expecting to land this in a few days. I
> anybody has xpcshell tests that are ready to land, I would suggest
> landing them sooner than later.
> 
> Thanks,
> Florian
> 
> -- 
> Florian Quèze
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev

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

Re: Bigger hard drives wanted (was Re: More ThinkStation P710 Nvidia tips (was Re: Faster gecko builds with IceCC on Mac and Linux))

[Michael de Boer]

I’d like to add the VM multiplier: I’m working mainly on OSX and run a Windows 
and a Linux VM in there with their own checkouts and objdirs. Instead of 
allocating a comfortable size virtual disks, I end up resizing them quite 
frequently to avoid running out of space to save as much as possible for OSX.

Mike.

> On 8 Nov 2017, at 17:28, Boris Zbarsky  wrote:
> 
> On 11/7/17 4:13 PM, Sophana "Soap" Aik wrote:
>> Nothing is worse than hearing IT picked or chose hardware that nobody
>> actually wanted or will use.
> 
> If I could interject with a comment about the hardware we pick...
> 
> The last desktop I was shipped came with a 512 GB drive.  One of our srcdirs 
> is about 5-8GB nowadays (we seem to have mach commands that dump large stuff 
> in the srcdir).
> 
> Each objdir is 9+GB at least on Linux.  Figure 25GB for source + opt + debug.
> 
> For the work I do (e.g. backporting security fixes every so often) I need a 
> release tree, a beta tree, and ESR tree, and at least 3 tip trees.  That's at 
> least 150GB.  If I want to have an effective ccache, that's about 20-30GB 
> (recall that each objdir is 9+GB!).  Call it 175GB.
> 
> If I want to dual-boot or have a VM so I can do both Linux and Windows work, 
> that's 350GB.  Plus the actual operating systems involved.  Plus any data 
> files that might be being generated as part of work, etc.
> 
> In practice, I routinely run out of disk space and have to delete objdirs and 
> rebuild them the next day, because I have to build something else in a 
> different srcdir...
> 
> -Boris
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

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

Re: Reminder on Try usage and infrastructure resources

[Michael de Boer]

> On 14 Sep 2017, at 17:48, Marco Bonardo  wrote:
> 
> When I need to retrigger a mochitest-browser test multiple times (to
> investigate an intermittent), often I end up running all the
> mochitest-browser tests, looking at every log until I find the chunk
> where the test is, and retrigger just that chunk. The chunk number
> changes based on the platform and debug/opt, so it's painful.
> Is there a way to trigger only the chunk that will contain a given
> test, so I can save running all of the other chunks?

This! This! This! I’d love to be able to do this - would making testing 
possible test failure fixes sooo much easier.

Cheers,

Mike.

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

PSA: add_task().skip() and add_task().only() are now available to three test suites

[Michael de Boer]

Dear devs,

Assuming the landing of patches in 
https://bugzilla.mozilla.org/show_bug.cgi?id=1380470 
 sticks, you all can 
enjoy the following from tomorrow onwards:

Paraphrased from the bug’s description:
You can now use `add_task(async function someTest() {}).skip()` and 
`add_task(async function someTest() {}).only()`, for Mochitest-chrome, 
Mochitest-browser and XPCShell tests, with the following semantics:

* `.skip()` makes sure that the task in question is not run as part of the 
suite. This will be made very clear in the log output as well.
* `.only()` makes sure that only the task in question is run, thus all the 
other tasks in that suite will be skipped. If `.only()` is called multiple 
times, it will run the last one on the stack, IOW: the last task on which 
`.only()` was called.

The motivation behind this feature is to promote Test Driven Development (TDD) 
and intermittent failure research work by allowing more granular control of 
what test gets run during your debugging process.
In large, growing test suites it's more likely that you'll be wishing to skip a 
certain test case because it takes a long time or has nothing to do with the 
failure case or rather to check if it pollutes the behavior of other tests.
In large, growing suites, it's also more likely that you'll be wishing for a 
convenient way to focus on a single test case, instead of the suite as whole. 
Example: extended feature development.

IMPORTANT: this change effectively deprecated XPCShell’s 
`add_test.skip(function test() {})`, `add_test.only(function test() {})`, 
`add_task.skip(async function test() {})` and `add_task.only(async function 
test() {})` in favor of the API mentioned above. This allowed for a 
substantially simpler implementation.

Thanks Standard8 (Mark Banner) for the idea and ahal (Andrew Halberstadt) for 
the reviews!

Enjoy and have fun,

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

Re: Intent to ship: IntersectionObserver API

[Michael de Boer]

Hi Tobias,

Very exciting! This is a _very_ welcome addition to the family of Web APIs, 
IMHO.

I’m curious about the performance characteristics for consumers of this API: 
how does it scale in respect to
1. The amount of observers active on a single page and
2. Size of the page in raw DOM node count, e.g. the single-page WHATWG HTML5 
spec?

Thanks,

Mike.


> On 15 Mar 2017, at 06:30, Tobias Schneider  wrote:
> 
> As of March 14 I intend to turn the IntersectionObserver API on by default
> on all platforms. It has been developed behind the
> dom.IntersectionObserver.enabled
> preference. Chrome is already shipping it since 51.
> 
> Manual QA and fuzzing was successfully completed (
> https://wiki.mozilla.org/QA/IntersectionObserver). A telemetry experiment
> run for 7 days, enabling the feature for 10% of our nightly (54 and 55)
> user population. No crashes or stability issues related to this feature
> occurred during that time.
> 
> *Bug to turn on by default*: https://bugzilla.mozilla.org/show_bug.cgi?id=
> 1321865
> *Link to standard*: https://wicg.github.io/IntersectionObserver/
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

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