Quantum Flow Engineering Newsletter #13

Hi everyone, I'm back with some more updates on another week worth of work on improving various performance aspects of Firefox. Similar to the past weeks, Speedometer remains a big focus area for performance work. In addition to the many already

Re: Shipping Headless Firefox on Linux

On Thu, Jun 15, 2017, at 09:37 PM, ISHIKAWA,chiaki wrote: > Interesting. > But this covers only modal prompts generated by/in JavaScript modules, > and not C++ code? > If so, maybe I should re-think my previous error/warning dialog to see > if the generation can be moved to JavaScript code. > It

Re: Shipping Headless Firefox on Linux

On 2017/06/16 6:47, Mike Hommey wrote: On Thu, Jun 15, 2017 at 04:51:48PM -0400, Ben Kelly wrote: On Thu, Jun 15, 2017 at 4:37 PM, Nathan Froyd wrote: On Thu, Jun 15, 2017 at 2:02 PM, Brendan Dahl wrote: Headless will run less of the platform specific

Re: Shipping Headless Firefox on Linux

On 2017/06/16 5:33, Andrew Sutherland wrote: On Thu, Jun 15, 2017, at 03:27 AM, ishikawa wrote: On local machine, when I added a modal error dailog as a response to an error condition, which happens to be artificially created and tested in xpcshell test, the test fails because the screen or

Re: Shipping Headless Firefox on Linux

On 2017/06/16 0:52, Brendan Dahl wrote: Depending on how the dialog was triggered, it may just work in headless mode. To run the test in headless mode, add "headless = true" to the test in your xpcshell.ini. Also, if you're in headless mode you can check it by calling gfxPlatform::IsHeadless()

Re: How are events passed between chrome and content?

On 6/15/17 4:12 PM, Kartikaya Gupta wrote: > Not quite. For e10s, mouse events are sent across the process boundary > using the PBrowser ipdl protocol. On the parent side they go into > EventStateManager::DispatchCrossProcessEvent [1] which picks up the > TabParent and sends it over IPC to the

Re: Shipping Headless Firefox on Linux

The width and height can be adjusted with the environment variables MOZ_HEADLESS_WIDTH and MOZ_HEADLESS_HEIGHT. We don't currently support DPI changes, but it shouldn't be too hard to add. On Thu, Jun 15, 2017 at 1:51 PM, Ben Kelly wrote: > On Thu, Jun 15, 2017 at 4:37 PM,

Re: Shipping Headless Firefox on Linux

I ran a few mochitests in headless mode awhile ago, so it's definitely feasible. I haven't looked into it much more yet, as I'm still trying to get a basic level of support to each platform. On Thu, Jun 15, 2017 at 1:37 PM, Nathan Froyd wrote: > On Thu, Jun 15, 2017 at 2:02

Re: Shipping Headless Firefox on Linux

On Thu, Jun 15, 2017 at 04:51:48PM -0400, Ben Kelly wrote: > On Thu, Jun 15, 2017 at 4:37 PM, Nathan Froyd wrote: > > > On Thu, Jun 15, 2017 at 2:02 PM, Brendan Dahl wrote: > > > Headless will run less of the platform specific widget code and I don't > > >

Re: How are events passed between chrome and content?

On Thu, Jun 15, 2017 at 4:16 PM, Jim Porter wrote: > From what I can tell, if I click inside a webpage, the event starts out > in chrome and then propagates down into content. I assume there's some > sort of magic happening in the message manager that pushes the event >

Re: Shipping Headless Firefox on Linux

On Thu, Jun 15, 2017 at 4:37 PM, Nathan Froyd wrote: > On Thu, Jun 15, 2017 at 2:02 PM, Brendan Dahl wrote: > > Headless will run less of the platform specific widget code and I don't > > recommend using it for platform specific testing. It is targeted

Re: Shipping Headless Firefox on Linux

On Thu, Jun 15, 2017 at 2:02 PM, Brendan Dahl wrote: > Headless will run less of the platform specific widget code and I don't > recommend using it for platform specific testing. It is targeted more at > web developers and testing regular content pages. There definitely will be

Photon Engineering Newsletter #6

(via https://dolske.wordpress.com/2017/06/15/photon-engineering-newsletter-6/) More exciting progress this week! Here’s Photon update #6 ! New Menus Work on the new Photon menus has reached the point where we’re ready to turn them on by default (for

Re: Shipping Headless Firefox on Linux

On Thu, Jun 15, 2017, at 03:27 AM, ishikawa wrote: > On local machine, when I added a modal error dailog as a response to an > error condition, which happens to be artificially created and tested in > xpcshell test, the test fails because the screen or whatever is not > available. Fair enough,

How are events passed between chrome and content?

>From what I can tell, if I click inside a webpage, the event starts out in chrome and then propagates down into content. I assume there's some sort of magic happening in the message manager that pushes the event across process boundaries. However, I can't figure out how to create my own event in

Re: Shipping Headless Firefox on Linux

At the moment, headless isn't much different than running with xvfb (besides being more convenient than installing xvfb). For the first stage, performance hasn't been the priority, but we expect some improvements and we'll be starting some work on this soon. Headless will run less of the platform

Re: Shipping Headless Firefox on Linux

I typically use xvfb-run when executing tests locally. How does headless mode differ? Does it just run faster, but at the cost not testing some widget code? On Wed, Jun 14, 2017 at 7:51 PM, Brendan Dahl wrote: > Hello All, > > > As of Firefox 55 I intend to ship headless

Re: Shipping Headless Firefox on Linux

Depending on how the dialog was triggered, it may just work in headless mode. To run the test in headless mode, add "headless = true" to the test in your xpcshell.ini. Also, if you're in headless mode you can check it by calling gfxPlatform::IsHeadless() in c++. On Thu, Jun 15, 2017 at 12:27 AM,

Re: Intent to unship: ISO-2022-JP-2 support in the ISO-2022-JP decoder

On Mon, Nov 30, 2015 at 5:38 PM, Henri Sivonen wrote: > Japanese *email* is often encoded as ISO-2022-JP, and Web browsers > also support ISO-2022-JP even though Shift_JIS and EUC-JP are the more > common Japanese legacy encodings on the *Web*. The two UTF-16 variants > and

Re: New character encoding conversion API

On 15/06/2017 12:32, Henri Sivonen wrote: * We don't have third-party crates in m-c that (unconditionally) require rust-encoding. However, if you need to import such a crate and it's infeasible to make it use encoding_rs directly, please do not vendor rust-encoding into the tree. Vendoring

Re: New character encoding conversion API

On Thu, Jun 15, 2017 at 6:32 AM, Henri Sivonen wrote: > encoding_rs landed delivering correctness, safety, performance and > code size benefits as well as new functionality. Thanks for working on this. > * We don't have third-party crates in m-c that (unconditionally) >

New character encoding conversion API

encoding_rs landed delivering correctness, safety, performance and code size benefits as well as new functionality. Here's a summary of need-to-know stuff from the perspective of using it. The docs for the Rust-visible API are at: https://docs.rs/encoding_rs/ The docs for the C++-visible API are

Re: Shipping Headless Firefox on Linux

On 2017年06月15日 08:51, Brendan Dahl wrote: > Hello All, > > > As of Firefox 55 I intend to ship headless Linux support (Firefox without a > GUI and X11 server connection). Headless mode is enabled via the --headless > command line flag for Firefox and does not affect Firefox when running in >