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

[Andrei Vaida]

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:


   https://public.etherpad-mozilla.org/p/DesktopManualQAWeeklyStatus



*Release Channel:*
none

*Beta Channel:*
NEW Bug 1216584  - 
Artifact on the downloads panel if the panel is opened during download

 • /Regression:/ Yes, since 2015-05-30.
 • /Severity:/ Normal.
 • /Assigned To:/ NOBODY.
NEW Bug 1217837  - 
Unable to load cloudsovercuba.com/

 • /Regression:/ No.
 • /Severity:/ Normal.
 • /Assigned To:/ NOBODY.
NEW Bug 1217844  - 
Visiting Addictinggames will result in very low browser performance or hangs

 • /Regression:/ No.
 • /Severity:/ Normal.
 • /Assigned To:/ NOBODY.
NEW Bug 1217824  - 
Broken folder tree in edit this bookmark menu

 • /Regression:/ No.
 • /Severity:/ Normal.
 • /Assigned To:/ NOBODY.

*Aurora Channel:*
NEW Bug 1216154 - 
Screen share button inactive if tab is shared before the call actually 
starts

 • /Regression:/ No.
 • /Severity:/ Normal.
 • /Assigned To:/ NOBODY.

*Nightly Channel:*
NEW Bug 1217426  - 
The inspector drop-down should display only the hidden tabs

 • /Regression:/ No.
 • /Severity:/ Normal.
 • /Assigned To:/ NOBODY.

*ESR Channel:*
none


Regards,
Andrei.
Andrei Vaida| QC Team Lead

SOFTVISION | 57 Republicii Street, 400489 Cluj-Napoca, Romania
Email: andrei.va...@softvision.ro  | 
Web: www.softvision.ro 


The content of this communication is classified as SOFTVISION 
Confidential and Proprietary Information.



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

sendKeyEvent doesn't support event.key

[Amit Zur]

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?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Philipp Kewisch]

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 Thunderbird. That may sound heartless, but it
> is the current directive from the organization that is paying us to work on
> m-c.

>From what I've understood from the build system folks, I think that
refactoring the build system without taking c-c into account wouldn't be
much of a problem if the merge happens.

There are Thunderbird folks that will happily use their free time to
look into bustages resulting from build system changes, we are already
doing that today.

If we can come to the agreement that patches to the m-c build system
done by Thunderbird folks won't be outright rejected, I think we are
good. Of course these patches should avoid being special cases, but if
an assumption is made in the build system that can be generalized, I
think it would be beneficial to both sides.

Philipp


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

Re: Intent to ship: WebVR

[Jet Villegas]

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 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:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1218482
>
> Link to standard: https://mozvr.github.io/webvr-spec/webvr.html
>
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Justin Dolske]

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 faster toward things such as stopping
supporting XUL addons, removing support for heavyweight themes, and even
cutting XUL altogether, we should all expect the impedance mismatch to
become worse. We are not only saying that you don't have to fix
comm-central apps: we're also saying that we don't *want* core
contributors to spend time on comm-central.


+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. Even in the "I'll just be nice and go a bit 
out of my way", because those costs are undervalued and add up.


This isn't out of spite or malice towards those projects, but a 
recognition that we need to focus our extremely limited time and 
resources. We're in a hypercompetitive market with giants (Google, 
Microsoft, Apple) who effectively have infinite time and resources in 
comparison. Constant distractions from our core do no one any good.


[And the same argument applies to things within Firefox as well - there 
are many things we could be doing, but need to aggressively focus our 
efforts on a few things that matter most.]


I'd also reiterate your point that this issue is, unfortunately, likely 
to get much worse as we start making deeper changes to modernize the 
platform (like de-XULification). I already see complaints from TB/SM 
folks about the difficulty in keeping pace today, and I'm not sure how 
those projects will realistically be able to keep up in the future. (And 
so it certainly seems like an odd time to be merging that code into 
mozilla-central.)


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

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

[Bobby Holley]

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
> c-c's presence in the repo.
>
> I can see that this might not be a satisfactory outcome to someone who
> just wants to pull the trigger and merge it all in so they can get cracking
> on build system improvements, without waiting on these annoying tooling
> considerations. But if so, why aren't the continued arguments focused on
> addressing BDS's (semi-)requirements? [note that gps *did* respond to the
> sparse checkout portion; is the current state of that support satisfactory?
> That's the blocking question here.]
>

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?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to ship: WebVR

[Kearwood "Kip" Gilbert]

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:
https://bugzilla.mozilla.org/show_bug.cgi?id=1218482

Link to standard: https://mozvr.github.io/webvr-spec/webvr.html


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

Re: Merging comm-central into mozilla-central

[Steve Fink]

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 optimize 
ourselves around that workflow.


Does this proposal come with a plan to check out subsets of the code? 
In particular, I want to express the following as something inbetween 
"serious concerns" and "requirements":


 * The default view of dxr.mozilla.org should not include non-Firefox 
code

 * The default checkout should not include non-Firefox code. (Note:
   this is about the working tree: I don't think the space in the .hg
   directory matters enough to worry about).


Why are we still arguing over this? It seems like BDS is fine with 
merging it back in, as long as some reasonable objections are resolved 
first.


With respect to the first one, I would personally like to further 
request that a non-default, relatively easily findable, view be 
available that *does* include non-Firefox code. I often search dxr for 
callers of a function where I *want* to see as many users as possible. I 
have no intention of "fixing" them, I just want to see them. It might be 
because I'm answering a question along the lines of "does anyone ever 
use it like this? Or have they in the past?" Or maybe I'm just searching 
for example code. Or maybe I'm implementing something for my static 
analysis and want to see whether it's worth handling a particular edge 
case. "If they did it once, they might try to do it again."


For my personal usage patterns, it is more common that I'd want to see 
results from m-c, c-c, external embedders, amo, and code from any other 
random clueless idiot on the internet. I would prefer to have a default 
view that showed anything from anywhere, with all past revisions 
included, but to have every result clearly denote whether it's from the 
current Firefox code (and have it sort those results to the top.) That 
"past revisions" part would clearly incur some performance 
considerations, but nothing that a dram or two of unicorn blood couldn't 
dispel away.


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 c-c's presence in the repo.


I can see that this might not be a satisfactory outcome to someone who 
just wants to pull the trigger and merge it all in so they can get 
cracking on build system improvements, without waiting on these annoying 
tooling considerations. But if so, why aren't the continued arguments 
focused on addressing BDS's (semi-)requirements? [note that gps *did* 
respond to the sparse checkout portion; is the current state of that 
support satisfactory? That's the blocking question here.]


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 seem hard.






- TTBOMK, Thunderbird is Mozilla's second largest project in terms of
   number of users, behind Firefox, and before Firefox for Android and
   Firefox OS.  Many of those users may legitimately want to contribute
   to Thunderbird, and the bar to entry is made much higher by the
   multi-repository setup and the extra complexity it entails. 
Mozilla is

   actively making the bar to entry for Firefox/Firefox for
   Android/Firefox OS contributions lower, at the expense of Thunderbird
   contributors. This is a sad state of affairs.


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 faster toward things such as stopping 
supporting XUL addons, removing support for heavyweight themes, and 
even cutting XUL altogether, we should all expect the impedance 
mismatch to become worse. We are not only saying that you don't have 
to fix comm-central apps: we're also saying that we don't *want* core 
contributors to spend time on comm-central.


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

Re: Merging comm-central into mozilla-central

[Nicholas Nethercote]

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 correct, though I'd rewrite it as the following:

"Given that people are already feeling pressure to fix up thunderbird
code when they land patches, we should make things easier by not
making them need to pull a separate tree."


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. Even in the "I'll just be nice and go a bit out
> of my way", because those costs are undervalued and add up.

Speaking for myself: even if I did ignore c-c, ignoring c-c doesn't
come with zero cost. Because if I change an API used by thunderbird
then a bug will be filed, and it will be marked as depending on the
bug in which I changed the API, and I'll see that in bugmail, and then
I'll read the bug, and feel bad that I inconvenienced someone -- but
I'll be strong, I'll ignore that bad feeling -- and then maybe they'll
need to needinfo me to ask about the change -- but maybe they should
know better, and maybe I should ignore them again -- and if I get CC'd
maybe I can just un-CC myself.

In comparison, for the cases I've experienced, modifying the TB code
is really simple. E.g. I'll have to modify 80 places in m-c code and
then 4 places in c-c code. Numbers like that.

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

Re: Merging comm-central into mozilla-central

[Philipp Kewisch]

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 _don't_ know they're allowed to break TB is real. That is
>> > the tradeoff that needs to be weighed IMO.
> 
> What Bobby said here seems very important. In the cost/benefit analysis,
> the impact on Firefox needs to be weighted very heavily. In particular,
> breaking TB should not cause failures either on try or on commit, and
> changes to pieces of Gecko should not be held up on their impact on TB.

If we get this right on the tooling side, I don't think it will be a
concern. For contributors that are regular Mozillians, I think it has
been clearly communicated that making changes in Firefox and Toolkit
does not require fixing Thunderbird/Seamonkey.

New contributors will either have a mentor that knows and can
communicate this fact, or will not see the changes when using a
correctly configured dxr, which is likely linked in one of the
contributor guides.

Even if they do a grep and find code locally, they will be aware that
Thunderbird and Firefox are separate products, and if they set out to
fix a Firefox bug I don't think they'd immediately think they need to
fix it in Thunderbird without asking questions. Personally I think they
will either ignore Thunderbird outright, or ask someone if they need to
take care of it. As per current policy, they will be told they do not
have to.

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

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

[Philipp Kewisch]

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, maybe we can see they are not so hard to fulfill and we
can come to an agreement quickly. Ideally, I'd like to find a middle
ground here that is acceptable to everyone.

Let me summarize requirements I have read:

* Thunderbird bustages should not close Firefox trees
* A version of dxr that does not show comm projects
* A version of dxr that shows all projects
* Treeherder remains separate
* Normal m-c try pushes don't automatically build Thunderbird
* There should be a commitment that comm projects will be regularly
maintained at least in the foreseeable future

* Thunderbird builds should not run on every m-c/m-i commit
* The default checkout should not contain comm projects
* It does not make sense if Thunderbird will be separate short term
* There should be least amount of pressure to fix Thunderbird things for
Firefox contributors


If these are the requirements, with the exception of narrow clones which
as I've understood are not stable yet, I believe they are all fairly
easy to fulfill.

Are there any other requirements I've missed?

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

Re: Merging comm-central into mozilla-central

[Philipp Kewisch]

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 fends for
> itself as pure downstream.
> 
> (1) seems strictly sub-optimal. The decision here is pretty much between
> (2) and (3).

I think there is another option here. Although I would of course prefer
(2), I think we could add:

(4) We land c-c in m-c, build peers ignore comm projects, TB folks help
with any build issues that break comm projects.

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

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

[Joshua Cranmer ]

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 (even for c-c contributors who want to make changes 
to m-c that affect both, such as myself) impossible still.


Obviously, I'm biased, but I still think that even that change would not 
ease up the difficulty of attracting new contributors, nor would it 
really solve the apparent goal of making c-c code invisible to m-c 
developers, since you'd see it if you accidentally checked out the 
default branch when tip was c-c and not m-c.



--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist

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

Re: Merging comm-central into mozilla-central

[Philipp Kewisch]

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 seem hard.

I think it is to early to take this into consideration. There are no
near-term plans to change Thunderbird to a model that would allow or
require splitting it out. I believe there are also at least a few
components that would require glue code or a customized Firefox runtime.
For example, I don't think registering for the default mail application
in windows is something that would work post xul in a pure html/js
environment.

If it turns out there is a way to do this with new API few years down
the road and it is determined that splitting Thunderbird out again
brings new advantages, we can still do that. A lot can change in that
time frame, both in Firefox and Thunderbird.

I support the merge.


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

Re: Merging comm-central into mozilla-central

[Jonas Sicking]

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 increasing
>> when you don't even need to pull a separate tree.
>
> That's more or less correct, though I'd rewrite it as the following:
>
> "Given that people are already feeling pressure to fix up thunderbird
> code when they land patches, we should make things easier by not
> making them need to pull a separate tree."

Well, that's exactly the question in this thread, isn't it.

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.

> 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. Even in the "I'll just be nice and go a bit out
>> of my way", because those costs are undervalued and add up.
>
> Speaking for myself: even if I did ignore c-c, ignoring c-c doesn't
> come with zero cost. Because if I change an API used by thunderbird
> then a bug will be filed, and it will be marked as depending on the
> bug in which I changed the API, and I'll see that in bugmail, and then
> I'll read the bug, and feel bad that I inconvenienced someone -- but
> I'll be strong, I'll ignore that bad feeling -- and then maybe they'll
> need to needinfo me to ask about the change

Yup. This matches my experience exactly. This is a good example of the
above mentioned friction.

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

Re: Merging comm-central into mozilla-central

[Brian Smith]

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 team is
> finding problems in Thunderbird and not properly notifying any Thunderbird
> developers of them.


Did you try clicking on the links in my emails?

> Here is a good example to show that the security of Thunderbird's
> S/MIME handling is not properly managed:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1178032

> You can see an example of this policy at work at
> https://bugzilla.mozilla.org/show_bug.cgi?id=1114787.

Love,
Brian
-- 
https://briansmith.org/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Steve Fink]

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. Just make it a long-lived 
branch. But would it serve the purpose of merging? Build system work 
would need the c-c bits, but then you'd want to merge that stuff back, 
which means cherry-picking build system changes or something.



That makes bisecting to find m-c-induced failures harder, and it also 
makes atomic commits (even for c-c contributors who want to make 
changes to m-c that affect both, such as myself) impossible still.


And build system changes are another example where you want atomic commits.



Obviously, I'm biased, but I still think that even that change would 
not ease up the difficulty of attracting new contributors, nor would 
it really solve the apparent goal of making c-c code invisible to m-c 
developers, since you'd see it if you accidentally checked out the 
default branch when tip was c-c and not m-c.





Not if c-c was on a branch.

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

Re: Merging comm-central into mozilla-central

[Joshua Cranmer ]

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 abilities.


The work required to actually do the merge is nothing more than a script 
I've already written and tested, as well as a few days with a release 
engineer to set up new configs. Ongoing maintenance would hopefully be 
minimal, as the difference would hopefully just be using one config file 
for Thunderbird and one for Firefox that differ only in things like 
choosing which mozconfig to use or choosing which directory to upload 
to, but I don't have a good enough insight into our build configuration 
to know for sure. Ongoing build system maintenance would probably be 
nil, excepting to-be-deprecated constructs which are used only in c-c 
(which I do try to keep on top of anyways, so that shouldn't be an issue).


As for the work required in build system to maintain the current 
state... There's a lot of hacks in the m-c build system to support 
Thunderbird, particularly the --external-top-srcdir configure option, 
the existence of multiple topsrcdirs, and checks for mozilla/ in several 
places (yeah, don't add a new mozilla/ source directory to the build 
system, things will break). The situation in release engineering is 
worse, since at this point we're using completely different build 
techniques, and it's hard or impossible for us to migrate to the 
mozharness-based builds, since mozharness is in mozilla-central and 
comm-central needs to do some build logic to figure out which version of 
mozilla-central (particularly on the Try server) to support. The build 
system support for the latter case also requires retaining partial 
duplication of some functionality in comm-central, resulting in a 
veritable Frankenbuild scenario.



On 10/23/15 6:15 PM, 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 foundation is going to give 
to Thunderbird.


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 
team is finding problems in Thunderbird and not properly notifying any 
Thunderbird developers of them.


--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist

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

Re: Merging comm-central into mozilla-central

[Philipp Kewisch]

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 foundation is going to give to Thunderbird.
> 
> I think that this decision really should be made by Mitchell (cced).
> 
> Doug

So there may be certain issues in S/MIME, but I don't believe that this
qualifies for a flat statement that Thunderbird is potentially harmful.

Nevertheless, I concur that working out an agreement on level of support
would be helpful. The Thunderbird Council is working hard on this, as it
would be of benefit for us too, but I don't think this should be a
strict requirement for merging m-c and c-c. Finding a complete strategy
for the future of Thunderbird takes time and a lot of communication with
Mozilla and other interested parties, merging m-c and c-c now would be
of immediate benefit for both sides.

Before we continue to loop in Mitchell here I think we should come to an
agreement on the technical side, there seem to be a few rough edges we
should iron out first.

Philipp

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

Re: Merging comm-central into mozilla-central

[Robert Kaiser]

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 friction by reducing collaboration" is 
to say that you are actively trying to kill Thunderbird and make their 
life as hard as possible. Is that what you are trying to say?


Otherwise, if we acknowledge that they can and should live, we need to 
see that we fix the friction by making collaboration easier.


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

Re: Merging comm-central into mozilla-central

[Nicholas Nethercote]

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 people in this thread, including build
system peers like glandium and gps whose opinion I think should hold
strong sway on the topic of repository structure.)

Do you have suggestions for achieving the second alternative?

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

Re: Merging comm-central into mozilla-central

[Ehsan Akhgari]

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. Even in the "I'll just be nice and go a bit out
of my way", because those costs are undervalued and add up.


Speaking for myself: even if I did ignore c-c, ignoring c-c doesn't
come with zero cost. Because if I change an API used by thunderbird
then a bug will be filed, and it will be marked as depending on the
bug in which I changed the API, and I'll see that in bugmail, and then
I'll read the bug, and feel bad that I inconvenienced someone -- but
I'll be strong, I'll ignore that bad feeling -- and then maybe they'll
need to needinfo me to ask about the change


Yup. This matches my experience exactly. This is a good example of the
above mentioned friction.


The example above talks about changing an API but there are more 
sophisticated issues in how these code bases interact.  I will cite one 
tricky example that I ran into over the past year or so.  I started to 
look into fixing some issues in our docencoder code that directly 
affects Firefox users.  Admittedly the m-c code was completely broken in 
interesting ways when I looked at it, but after I landed my initial 
change I started to see a torrent of regressions in Thunderbird, and as 
I fixed more of the code I ended up breaking more and more in 
Thunderbird.  I spent quite a bit of time debugging the c-c side of 
things and I ended up adding some Thunderbird specific hack 
 
that is basically me avoiding rewriting the Thunderbird code hooking 
into the Gecko guts, and in some other cases I ran into issues where I 
didn't understand what behaviors Thunderbird actually relies on, the 
result of which is many unfixed regressions that are still on my plate.


If the Thunderbird code was in the tree, I would have found the broken 
code in question by grepping and I think I would probably avoid 
modifying the code after seeing the Thunderbird usage of the code 
altogether.  That would have meant I would have gotten quite a bit of my 
weekends back which is a good change for me, but it would also mean that 
none of the broken behavior in Firefox would have been fixed, which 
would be a bad change for Firefox users.  (I have effectively decided to 
avoid this code like the plague because of the way Thunderbird uses it, 
but at least now some of the fixes are already in m-c...

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

Re: Merging comm-central into mozilla-central

[Ehsan Akhgari]

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 work for
contributors that _don't_ know they're allowed to break TB is real. That is
the tradeoff that needs to be weighed IMO.


What Bobby said here seems very important. In the cost/benefit analysis,
the impact on Firefox needs to be weighted very heavily. In particular,
breaking TB should not cause failures either on try or on commit, and
changes to pieces of Gecko should not be held up on their impact on TB.


If we get this right on the tooling side, I don't think it will be a
concern. For contributors that are regular Mozillians, I think it has
been clearly communicated that making changes in Firefox and Toolkit
does not require fixing Thunderbird/Seamonkey.


This is I think the crux of the issue.  "Making changes in Firefox 
doesn't require fixing Thunderbird/SeaMonkey" is far away from the truth 
in practice.


Over the years I have gained a *ton* of experience in code that 
interfaces with both Firefox and Thunderbird/SeaMonkey.  I can't really 
think of a single instance where I made a change in that code and it 
broke something in Thunderbird and the breakage was magically fixed 
without my involvement.


What happens in practice is people file bugs and ping you and unless 
we're talking about a very simple API change that is obvious to mirror 
in c-c, nobody will do anything about the regression unless if the 
Firefox developer looks at it.  So it's a choice between actively 
ignoring people (which is really being rude to them, which is not an 
option I would personally take) or having to do some work (which often 
involves reading and understanding the c-c code, debugging it, and so on.)


Now, as an employee of MoCo, I am told to spend 0 time on these issues. 
 Therefore, I try to be responsible, and nice, and spend my spare time 
to fix them.  (Saying this part with the best possible intentions) And 
you've seen how I have been treated elsewhere in the thread, in the 
sub-thread that I stopped participating in.  This situation is really 
not sustainable for a healthy community.


To me it's completely clear that the rule on paper that we have for not 
worrying about c-c has failed in practice.  I think any technical 
decision based on the imaginary idea that people can just ignore TB/SM 
code is doomed to fail.


In the past I have supported moving c-c into m-c.  I was the person who 
filed  three years 
ago.  I still think that this decision makes perfect sense from a 
technical point of view.  Every time that we have merged a satellite 
repository into m-c the result has been a net win for the ongoing 
technical work.


But there is also the policy side of things.  At Mozilla we typically 
make rules by documenting existing practices, but this is one of those 
cases where existing practices differ wildly with the rules.  I used to 
think that it's OK to just ignore the policy side of things and focus on 
the technical work, but from my personal experience the result of doing 
that is different individuals spend varying amounts of efforts on c-c 
issues (varying from 0 to substantial amounts of time) and they're all 
treated as if everyone's spending 0 amount of time, because that's what 
the rules say.


This leaves a pretty bad taste on a personal level.  But at the project 
level, it is detrimental to the health of our communities, and as a 
result to the quality of Thunderbird and SeaMonkey (and thirdly Firefox).


I have come to the conclusion that it's been a mistake to ignore the 
policy side of things in these discussions.  I honestly don't know what 
the right solution is, but I think that reducing this issue to just the 
technicality of where the source code lives is not a good way to go forward.


Best regards,
Ehsan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Mitchell Baker]

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 obvious "no."  My 
clear recollection is that Brendan was of the view we had reached that 
point a while back, and that Thunderbird should be more separate from 
firefox-centric systems, not less. And that he was vehement about not 
merging the two repos.


In an ideal world I agree that separating the two so that Thunderbird 
team is not spending so much time dealing with Firefox systems is much 
better for thunderbird.  I also suspect that this will become more true 
over time, not less.  And I agree that Firefox and our new products will 
benefit from having a clean separation, and that we need all the forward 
momentum we can get if we are going to impact the state of the web in 
the future.


I'm not sure we're able to do this, so need to do some due diligence to 
figure out what the ideal world today is.  I personally still live in 
Thunderbird, so am interested both for the sake of the thunderbird the 
open source project, and for my own personal daily experience.


As I said, more shortly, i'm running late now.

mitchell

On 10/23/15 6:15 PM, 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 foundation is going to give to Thunderbird.

I think that this decision really should be made by Mitchell (cced).

Doug



On Oct 23, 2015, at 7:32 PM, Robert O'Callahan  wrote:

On Sat, Oct 24, 2015 at 12:43 PM, Jonas Sicking  wrote:


But I think that the clear directive from project leadership has been
to prioritize Firefox development over other Gecko based projects.


I don't think that's unqualified. If killing off Thunderbird forever saves
a Firefox developer five minutes of work (e.g. by putting an end to this
thread), should we go ahead and do that because we're supposed to be
prioritizing Firefox development? I think clearly we shouldn't do that. We
should give Thunderbird some consideration.

I support merging c-c into m-c.

Rob
--
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
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: Intent to ship: WebVR

[Ehsan Akhgari]

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 
high-level overviews of what the DOM interfaces do, rather that detailed 
descriptions that can be used in order to implement the specification.


Also some things that I was expecting to see in the API seem to be 
missing.  For example, what should happen if the VR device is 
disconnected as the application is running?  It seems like right now the 
application can't even tell that happened.


Another question: do you know if Chrome is planning to ship this feature 
at some point?  Has there been interoperability tests?


Do we know what the other browser vendors think of the API and the 
specification?


Thanks,
Ehsan

On 2015-10-26 3:19 PM, Kearwood "Kip" Gilbert wrote:

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:
https://bugzilla.mozilla.org/show_bug.cgi?id=1218482

Link to standard: https://mozvr.github.io/webvr-spec/webvr.html


___
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: Merging comm-central into mozilla-central

[Jonas Sicking]

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 see a lot that has gotten easier because we change platform
> and Firefox (mostly) without caring if we break Thunderbird or SeaMonkey

For two reasons.

First of all it'll be hard for developers to tell that they don't have
to fix certain pieces of code. A simple grep will turn up all hits in
the tree, whether they live in thunderbird code or not. And, at least
currently, mxr/dxr would return hits for all code.

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.

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

Re: sendKeyEvent doesn't support event.key

[smaug]

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 fixed any time soon?




You probably want to use 
http://mxr.mozilla.org/mozilla-central/source/dom/interfaces/base/nsITextInputProcessor.idl

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

Re: Merging comm-central into mozilla-central

[Robert Kaiser]

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 enables building all downstream products. It's the
responsibility of downstream products to trigger the build system of
libraries.


Yes, but our platform is not built in a way to really be able to act as 
an outside library to Thunderbird (or SeaMonkey). The idea to get it 
there was around years ago, under different names (the last of them 
being XULRunner) and it failed. So what we have is "you need to build 
all the platform code if you want to build Thunderbird, and you need to 
compile your Thunderbird-specific code into libxul even". And I think 
that's the reason where this view you bring up there doesn't apply to 
what we have.
Maybe, some years down the road, when Firefox and Thunderbird UI are all 
standard HTML, this will be all different, but until then, lives are 
much easier when all this lives into a common repository.



The goal of putting seamonkey and thunderbird in separate trees has
always been to make firefox development easier, not harder. That
should include the build system.


That was the idea, yes. In reality, we have found out that this made it 
harder, especially for the build system, and we are continuing to waste 
a lot of developer time because making sure that the build system at 
least stays usable to Thunderbird (and SeaMonkey) is slowing efforts 
down to make our build system modern and give it all kinds of 
optimizations like caching, dependency-awareness and whatnot that will 
improve development speed for all platform and Firefox developers.


As the on-paper-owner of the comm-central build system, I would heavily 
appreciate this merge (and killing off "my" module and the repository I 
created way back).


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

Re: Merging comm-central into mozilla-central

[Robert Kaiser]

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) without caring if we break Thunderbird or 
SeaMonkey - and I think that isn't necessarily related with where the 
code actually lives.


I see where the code lives as a technical issue and how much or if we 
care to break those products when changing code as a policy issue. And I 
don't think that the proposal here is to change policy there.


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

Re: Merging comm-central into mozilla-central

[Robert Kaiser]

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 actually one of the people doing a ton 
of work there. ;-)



From all I see and hear, those people active in the SeaMonkey project 
are committed to maintaining it for the foreseeable future.
You never know what happens years down the road, of course, and this is 
a small group of people. But then, from its inception, this was a pretty 
small group, and the project has survived for 10 years now (founded in 
March 2005, 1.0 release in January 2006).


The project has been having build infrastructure issues in recent 
months, but I hear things are somewhat improving - and actually, this 
merge would probably make quite a few things easier, as more of the same 
tooling could be used that Firefox uses (for example, all the custom 
buildbot tooling I wrote up years ago for handling c-c is a major PITA 
up to this day).


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