[Firefox Desktop] Issues found: October 19th to October 23rd

Hi everyone, Here's the list of new issues found and filed by the Desktop Manual QA team last week (Week 43: October 19 - October 23). Additional details on the team's priorities last week, as well as the plans for the current week are available at:

sendKeyEvent doesn't support event.key

MDN says keyCode is deprecated and web developers should favor `key` instead. But sendKeyEvent doesn't support key property on the event. I found bug #1214993 but the solution there is a workaround for the home button for TV. Can we expect this to be fixed any time soon?

Re: Merging comm-central into mozilla-central

On 10/23/15 11:22 PM, Bobby Holley wrote: >> What's even more sad is that it's at the expense of Thunderbird (and >> > SeaMonkey) *and* at the expense of Firefox build system changes. >> > > That may be a reason for the people working on the build system to refactor > it without consideration for

Re: Intent to ship: WebVR

Let the record state that Firefox is first to deliver Web Virtual Reality to Planet Earth. On to other (virtual) worlds... Congratulations, VR Team! \o/ --Jet On Tue, Oct 27, 2015 at 4:19 AM, Kearwood "Kip" Gilbert < kgilb...@mozilla.com> wrote: > As of Oct 29, 2015 I intend to turn WebVR on

Re: Merging comm-central into mozilla-central

On 10/23/15 10:22 AM, Benjamin Smedberg wrote: I'm sorry that it makes you sad, but Mozilla has explicitly decided to prioritize the bar to entry for Firefox development, and the speed of development of Firefox, at the expense of Thunderbird (and seamonkey). And as Firefox development moves

Spare Checkouts (Was: Merging comm-central into mozilla-central)

On Mon, Oct 26, 2015 at 2:05 PM, Steve Fink wrote: > For the second one, it feels like a bit of a scary amount of complication > in order to avoid seeing distracting code during a typical grep, but it > also feels like a good pragmatic way to minimize the distraction caused by

Intent to ship: WebVR

As of Oct 29, 2015 I intend to turn WebVR on by default for all platforms. It has been developed behind the dom.vr.enabled preference. A compatible API has been implemented (but not yet shipped) in Chromium and Blink. Bug to turn on by default:

Re: Merging comm-central into mozilla-central

On 10/23/2015 10:22 AM, Benjamin Smedberg wrote: I support going back to a giant monolithic repository if we can cleanly delineate the code for various projects. We know that the searchability and readability of our code is a major barrier to some kinds of participation. We should continue to

Re: Merging comm-central into mozilla-central

On Mon, Oct 26, 2015 at 11:39 AM, Jonas Sicking wrote: > > Given that people are already feeling pressure to fix up thunderbird > code when they land patches, I can only see that pressure increasing > when you don't even need to pull a separate tree. That's more or less

Re: Merging comm-central into mozilla-central

On 10/23/15 11:09 PM, Eric Rescorla wrote: >> It may well be that having c-c code in m-c decreases friction overall, >> > since it saves time for the people that know they're allowed to break TB >> > but choose to help it anyway. However, the cost of redirected work for >> > contributors that

Re: Merging comm-central into mozilla-central (summary v1)

Hi all, I'd love to see if we can move towards an agreement. For those of you that would prefer not to merge, I'd love to hear what your absolute minimum requirements would be that you'd accept a merge with. Changes to hg? Changes to dxr? A policy chanage? If we can establish clear requirements,

Re: Merging comm-central into mozilla-central

On 10/24/15 1:41 AM, Bobby Holley wrote: > We have three options: > (1) Build peers do a bunch of extra work to support c-c in a separate repo. > (2) We land c-c in m-c, so that build peers can support it without much > extra work. > (3) We don't land c-c in m-c, build peers ignore c-c, and TB

Re: Spare Checkouts (Was: Merging comm-central into mozilla-central)

On 10/26/2015 4:16 PM, Bobby Holley wrote: Question: Would we actually need sparse checkouts? What if c-c was just a branch in the repo with extra stuff, which periodically took merges from m-c? That makes bisecting to find m-c-induced failures harder, and it also makes atomic commits

Re: Merging comm-central into mozilla-central

On 10/26/15 10:05 PM, Steve Fink wrote: > > Perhaps the concern is that it's foolish to merge it in now if the > direction of c-c development is going to end up needing it split out > eventually anyway? I doubt that's near enough at hand to matter, > personally, and splitting it back out doesn't

Re: Merging comm-central into mozilla-central

On Mon, Oct 26, 2015 at 3:45 PM, Nicholas Nethercote wrote: > On Mon, Oct 26, 2015 at 11:39 AM, Jonas Sicking wrote: >> >> Given that people are already feeling pressure to fix up thunderbird >> code when they land patches, I can only see that pressure

Re: Merging comm-central into mozilla-central

On Mon, Oct 26, 2015 at 1:45 PM, Joshua Cranmer  wrote: > FWIW, when Brian Smith made his comments on mozilla.dev.security.policy, I > did try to find a bug detailing what he was talking about... and I couldn't > find what he was talking about, which means that our security

Re: Spare Checkouts (Was: Merging comm-central into mozilla-central)

On 10/26/2015 04:01 PM, Joshua Cranmer  wrote: On 10/26/2015 4:16 PM, Bobby Holley wrote: Question: Would we actually need sparse checkouts? What if c-c was just a branch in the repo with extra stuff, which periodically took merges from m-c? That seems like a simple and tempting idea.

Re: Merging comm-central into mozilla-central

On 10/23/2015 8:25 PM, Mitchell Baker wrote: Yes, this is a good topic and I agree i'm a necessary party here. Is there some way of getting a good sense of the work that we're talking about? I'm not sure which work you're referring to here, but I will try to answer to the best of my

Re: Merging comm-central into mozilla-central

On 10/24/15 3:15 AM, Doug Turner wrote: > Thunderbird is under supported and potentially harmful (as Brian Smith > pointed out on the mozilla-dev-security-policy back in Sept). Before merging > c-c into m-c, I think we should have agreement on what kind of support the > mozilla project and

Re: Merging comm-central into mozilla-central

Jonas Sicking schrieb: Everyone acknowledges that there's currently friction due to the way that collaboration with thunderbird is done. The question is, do we fix that friction by making collaboration easier, or do we fix it by reducing collaboration. I think the only way to "fix the

Re: Merging comm-central into mozilla-central

On Tue, Oct 27, 2015 at 10:26 AM, Jonas Sicking wrote: > > The question is, do we fix that friction by making collaboration > easier, or do we fix it by reducing collaboration. Yes. Merging c-c into m-c would achieve the first alternative. (And it has support from plenty of

Re: Merging comm-central into mozilla-central

On 2015-10-26 7:26 PM, Jonas Sicking wrote: On Mon, Oct 26, 2015 at 1:29 PM, Justin Dolske wrote: +1. Last time this thread came up, I thought the guidance was that core contributors (and especially MoCo employees) should explicitly *not* be spending time on TB/SM code.

Re: Merging comm-central into mozilla-central

On 2015-10-26 7:17 PM, Philipp Kewisch wrote: On 10/23/15 11:09 PM, Eric Rescorla wrote: It may well be that having c-c code in m-c decreases friction overall, since it saves time for the people that know they're allowed to break TB but choose to help it anyway. However, the cost of redirected

Re: Merging comm-central into mozilla-central

I'm in the middle of a hectic business trip, so will write more while i"m on the plane home tonight. The first thing to figure out, as Doug said, is how much support the project should provide Thunderbird. 5 minutes might be an obvious yes, as noted earlier. At some level the answer is an

Re: Intent to ship: WebVR

First things first, congratulations on getting this close! What's the status of the specification? I just had a quick skim and it seems extremely light on details. There is quite a bit of details missing. The security model is essentially blank, and the descriptions in section 4 seem to be

Re: Merging comm-central into mozilla-central

On Mon, Oct 26, 2015 at 9:20 AM, Robert Kaiser wrote: > Jonas Sicking schrieb: >> >> I definitely think that some aspects of Firefox development has gotten >> easier thanks to the split. > > I'd like to see which. I don't see much that has gotten easier *because of > the split*. I

Re: sendKeyEvent doesn't support event.key

On 10/26/2015 10:21 AM, Amit Zur wrote: MDN says keyCode is deprecated and web developers should favor `key` instead. But sendKeyEvent doesn't support key property on the event. I found bug #1214993 but the solution there is a workaround for the home button for TV. Can we expect this to be

Re: Merging comm-central into mozilla-central

Jonas Sicking schrieb: Would it be possible to create a thunderbird build system which simply takes the output of a firefox build and grabs the files that it needs, and builds the additions that thunderbird needs. Generally speaking, libraries don't worry about having a build system which

Re: Merging comm-central into mozilla-central

Jonas Sicking schrieb: I definitely think that some aspects of Firefox development has gotten easier thanks to the split. I'd like to see which. I don't see much that has gotten easier *because of the split*. I see a lot that has gotten easier because we change platform and Firefox (mostly)

Re: Merging comm-central into mozilla-central

Edmund Wong schrieb: As for the long term plans, I'll wait for one of the SeaMonkey council members to comment on that; but I believe we are determined to maintain the SeaMonkey code. I'll weigh in as a SeaMonkey Council member - even though I mostly watch what's going on while Edmund is