Re: Intent to implement: Async Clipboard API
That would be really awesome to get rid of all Gtk+/Clipboard hacks we
have there to transfer async clipboard on Linux to sync at Geckoso
does it mean we can provide async clipboard only on toolkit/widget code
level?
ma.
On 05/14/2018 11:05 PM, Nika Layzell wrote:
In about a week, my intern will be starting. As an initial project, I
intend for her to implement the Async Clipboard API.
Summary: The Async Clipboard API provides a more modern and performant
interface to the user's clipboard. This API is intended to replace many
consumers of the existing `document.execCommand("copy"/"cut")`.
Example Usage:
navigator.clipboard.writeText("text").then(...)
Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1461465
Link to standard: https://w3c.github.io/clipboard-apis/#async-clipboard-api
Platform coverage: All
Estimated or target release: Firefox 63 (estimated)
Preference behind which this will be implemented:
'dom.events.asyncClipboard'
The full `write`/`read` APIs will be exposed to the web behind an
additional
preference of 'dom.events.asyncClipboard.dataTransfer', so we can ship
the text APIs separately.
DevTools bug: N/A
Do other browser engines implement this?
Chrome: Shipped (since version 66)
Edge, Safari: Public Support (according to
https://www.chromestatus.com/features/5861289330999296)
web-platform-tests: A test for this API has already been created by the
chrome team (
https://searchfox.org/mozilla-central/rev/2b9779c59390ecc47be7a70d99753653d8eb5afc/testing/web-platform/tests/clipboard-apis/async-navigator-clipboard-basics.https.html
)
Secure Contexts Only: Yes, this API will only be exposed to secure contexts.
Security & Privacy Concerns: This API exposes no new capabilities to the
web platform. Instead, it provides a more performant and ergonomic API to
replace most users of `execCommand("copy"/"cut")`. -- We do not intend to
expose the ability to read from the clipboard (the Clipboard.read and
Clipboard.readText APIs) to the web at this time. These APIs will only be
usable by extensions which have requested the appropriate permissions. --
Exposing `Clipboard.write` (the full DataTransfer API) to the web will also
occur behind a separate preference.
___
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: Linux distro readiness for Rust in Gecko
On 03/17/2016 11:59 AM, Henri Sivonen wrote: Do we have a plan being executed to make sure that when Gecko components written in Rust ship on the release channel in Mozilla-produced builds the also ship in the Firefox packages of various Linux distributions? If not, we really need to put such a plan in place, since it would be bad to have a conflict between our ability to reach Linux users and our ability to benefit from Rust quickly. My concern is that Linux distributions tend to have a policy that binary packages have to be buildable from source packages using the tools that are available in the package repository of the distro. Considering the current state of rustc availability in distro repositories, it seems to me that we are headed towards a problem. As far as I can tell, of the well-known distributions only Arch and openSUSE have the current rustc in their package repositories (and the openSUSE packages are categorized as "unstable"). Debian has it in unstable and testing only. Gentoo is a couple of rustc releases out of date. Ubuntu and Fedora don't have any version of rustc anywhere at all. At least in the case of Fedora, just shipping a rustc binary alongside the Firefox source is explicitly not good enough for their policy: https://fedoraproject.org/wiki/Packaging:Guidelines#No_inclusion_of_pre-built_binaries_or_libraries Yes, that's not possible in Fedora - we have similar problem with pre-built signed extensions from AMO. Is it possible to build Rust from sources before Firefox build executes? That may be a solution for now and it ensures that the Rust is always up to date. ma. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Linux distro readiness for Rust in Gecko
On 03/17/2016 01:47 PM, Sylvestre Ledru wrote: [...] One way which would make the life of Linux distro way easier would be to maintain the Firefox rust code in a way it could compile using older rust compiler. For example, imagine that the next Debian stable or Ubuntu LTS ships using Rust 2.0, we would make sure that the new rust code still compile with Rust 2.0 (limiting our capability to use new language trick). Just like we do with C++... Now, with my Debian/Ubuntu hat, maintaining rust backports to be able to build new versions of Firefox on stable/LTS releases is not going to be easy: rust needs recent versions of LLVM, LLVM is a complex beast (with regular bump the minimal version of gcc, etc). And here, I am just mentioning i386 & amd64... (Debian/ubuntu don't have any rust builds for arm CPU). Well, what about other arches? ppc(64), s390, ai64...? Sylvestre ___ 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: Terminating xulrunner?
Well, Fedora is going to ship standalone Firefox instead of the FF+XL combo and retire the xulrunner package. ma. On 01/13/2014 01:34 AM, Mike Hommey wrote: Hi, Let's face it: xulrunner is hardly maintained, we barely build and test it on automation, and the result is that it is often broken for long periods of time. I propose that we just stop pretending, and terminate xulrunner, considering the following: - Xulrunner is lagging behind Firefox: DLL block list, startup telemetry, etc. - Since bug 755724, running firefox -app application.ini is 99% the same as running xulrunner application.ini, except for a few details that should be considered bugs. Before that bug, it was quite different, as browser-specific files were available to the xul application. - There is no reason we can't generate the sdk from firefox instead of xulrunner. Moreover that would make firefox-specific interfaces available in the sdk that aren't currently (which may or may not be a good thing, arguably) - We could include the xulrunner and xulrunner-stub executables as part of firefox. xulrunner-stub is small and self-contained, and xulrunner could be replaced by something that calls firefox -app. Or we could make the firefox executable check under what name it's called and act accordingly. Thoughts? Mike ___ 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: GTK3 linux builds
On 06/17/2015 01:01 AM, Mike Hommey wrote: On Tue, Jun 16, 2015 at 05:57:49PM -0400, Hubert Figuière wrote: On 16/06/15 05:13 PM, Jeff Muizelaar wrote: Is there any reason not to support all the way back to the version of GTK (3.4) on the test machines? Between 3.10 and 3.14 there are bugs in the drag and drop code in Gtk3 that make Firefox (for Gtk3) unusable. https://bugzilla.mozilla.org/show_bug.cgi?id=983843 See upstream https://bugzilla.gnome.org/show_bug.cgi?id=728183 This was why I actually suggested bumping to 3.14. You also didn't answer whether the builds done with gtk 3.4 on the elm branch exhibit the problem when running with gtk 3.14. This particular bug is in Gtk3 internal timer loop - it stops when D&D target/source windows is not visible. So it depends on running instance of Gkt3 only. ma. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: GTK3 linux builds
On 06/17/2015 01:01 AM, Mike Hommey wrote: On Tue, Jun 16, 2015 at 05:57:49PM -0400, Hubert Figuière wrote: On 16/06/15 05:13 PM, Jeff Muizelaar wrote: Is there any reason not to support all the way back to the version of GTK (3.4) on the test machines? Between 3.10 and 3.14 there are bugs in the drag and drop code in Gtk3 that make Firefox (for Gtk3) unusable. https://bugzilla.mozilla.org/show_bug.cgi?id=983843 See upstream https://bugzilla.gnome.org/show_bug.cgi?id=728183 This was why I actually suggested bumping to 3.14. A quick look at GTK_CHECK_VERSION() gives me: http://mxr.mozilla.org/mozilla-central/search?string=GTK_CHECK_VERSION&case=1&find=&findi=&filter=^[^\0]*%24&hitlimit=&tree=mozilla-central Build for gtk3.4 means to ship this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=931378 and checkboxes lose visible checked state when running on Gtk3.14: http://hg.mozilla.org/mozilla-central/rev/276096579e7d which IMHO can be worked out. Mike, are there any Gtk3.4 based builds available? I'd like to test them on latest Gtk3 releases to confirm it works. ma. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: GTK3 linux builds
On 06/17/2015 08:49 AM, Martin Stransky wrote: On 06/17/2015 01:01 AM, Mike Hommey wrote: On Tue, Jun 16, 2015 at 05:57:49PM -0400, Hubert Figuière wrote: On 16/06/15 05:13 PM, Jeff Muizelaar wrote: Is there any reason not to support all the way back to the version of GTK (3.4) on the test machines? Between 3.10 and 3.14 there are bugs in the drag and drop code in Gtk3 that make Firefox (for Gtk3) unusable. https://bugzilla.mozilla.org/show_bug.cgi?id=983843 See upstream https://bugzilla.gnome.org/show_bug.cgi?id=728183 This was why I actually suggested bumping to 3.14. A quick look at GTK_CHECK_VERSION() gives me: http://mxr.mozilla.org/mozilla-central/search?string=GTK_CHECK_VERSION&case=1&find=&findi=&filter=^[^\0]*%24&hitlimit=&tree=mozilla-central Build for gtk3.4 means to ship this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=931378 and checkboxes lose visible checked state when running on Gtk3.14: http://hg.mozilla.org/mozilla-central/rev/276096579e7d which IMHO can be worked out. Works fine for me - builds from Mike's elm on Fedora 22 / Gtk 3.16. The checkbox Bug 931378 is not exposed here. ma. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: GTK3 linux builds
On 07/20/2015 03:30 PM, Robert O'Callahan wrote: On Tue, Jul 21, 2015 at 1:04 AM, Jeff Muizelaar wrote: I believe Flash does. OK, I can't get it to work, but I think it's just my system. I verified that Fedora 22 (and I think 21) shipped GTK3 Firefox. If there aren't any major blocking bugs for GTK3 >= 3.4, and the tests are green, I think we should switch to GTK3 immediately and stop doing GTK2 builds. I know the bugs mentioned in the thread above are fixed for GTK >= 3.4. Only Fedora 22 has Gtk3 Firefox and I don't see any complains about flash. But it carries lots of Gtk3 patches from Firefox 40-41 (and maybe 42) - widget layout/borders patches, tab styles and so on. ma. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Status of Ubuntu 20.04 as a development platform
On 11/10/20 12:48 PM, Henri Sivonen wrote: Does Ubuntu 20.04 work properly as a platform for Firefox development? That is, does rr work with the provided kernel and do our tools work with the provided Python versions? It would be great to have Ubuntu 20.04 option in try to test Firefox Wayland backend on it. -- Martin Stransky Software Engineer / Red Hat, Inc ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: XUL Runner, and the future.
On 08/16/2012 12:51 PM, Neil wrote: Dave Townsend wrote: On 08/15/12 12:41, Ben Hearsum wrote: On 08/15/12 02:57 PM, Justin Wood (Callek) wrote: XULRunner is currently an unsupported piece of software, we don't run tests for it, and we *barely* ensure it still builds. I don't think this is true. It's not tier1, but we ship it with every release and beta. However, I'd be surprised if there was any guarantee that it will exist in 5-10y though. I think it's true. We don't have any automated tests that verify that the build works beyond compiling and it was totally failing on most platforms for 2-3 releases. Right now there are a couple of us that attempt to keep it going but I have no idea how long that will last. Thankfully XULRunner is a simple enough extension of the core pieces of Firefox that the potential for breakage is pretty small, this is probably the only reason it is still alive. I'm not sure its chances are good if we make a change that requires a lot of work to keep XULRunner working. Aren't there linux distros trying to ship Firefox + Thunderbird + XULRunner? Sadly I doubt we have the capacity, but I would have thought that all our existing tests should work just as well on a Firefox/Thunderbird + XULRunner build as on a monolithic build. Yes we still ship Xulrunner in Fedora/RHEL, for the SDK and future Thunderbird release. ma. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
