Re: Workaround for building with Visual Studio 15.7+

[Frank-Rainer Grahl]

15.8 finally fixed the compiler bug and starting with preview 4 I also got a 
good executable out. Had problems here with preview 3.


15.8 needs a configure fix for _RAISE.

Only compiled the comm-esr52 tree with backports to support VS2017 and 
comm-esr60 right now. Only x64 too.


FRG


Jeff Gilbert wrote:

FWIW, I found that building with clang-cl works fine out-of-the-box
with 15.7.x, and the Installer tells me that I don't have the 15.6
toolset installed. YMMV, but I've found that clang-cl builds Just Work
with 15.7.

On Thu, Aug 16, 2018 at 5:23 AM, Gabriele Svelto  wrote:

  Hello all,
being among those unfortunate enough to have updated Visual Studio
before realizing that the most recent version cannot be used to build
Firefox, I was faced with the prospect of reinstalling the whole
monstrosity - which takes forever - or finding a workaround. As it turns
out I found a clunky yet simple one:

- Launch the Visual Studio Installer, the click on the "modify" button

- Go into the "Individual components" and select the "VC++ 2017 version
15.6 v14.13 toolset" component

- Launch the installation

- Modify build/moz.configure/toolchain.configure by manually setting the
tools_version string in [1] to the value '14.13.26128'

- You're done! Both a clang-cl and a msvc should now pick up the old
tooling and work properly (provided you have the right Windows SDK).

I couldn't find a way to override this via mozconfig options or
environment variables but if there is a way to do this without modifying
the sources I'd like to hear it.

  Gabriele

[1]
https://searchfox.org/mozilla-central/rev/5dbfd833bbb114afe758db4d4bdbc5b13bcc33ef/build/moz.configure/toolchain.configure#584


___
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: XUL Overlays Removed

[Frank-Rainer Grahl]

> This is just one piece of the broader XUL removal effort, but it does
> highlight that things can be simpler in a post-XUL world.

Well I agree that cleaning up overlay usage was overdue. Otherwise the simple 
post XUL world world is just dumb. Removing things without a functional 
replacement and putting in spaghetthi code seems to be the current mantra. 
Preprocessing with include files is even worse.


FRG


Brendan Dahl wrote:

This is hopefully the last thing you’ll ever hear about XUL overlays as
they have now been completely removed from Firefox[1]. For those unfamiliar
with overlays, they provided a way to merge two XUL documents and were
mainly used by legacy extensions and in several places within the Firefox
UI. While overlays served a purpose, they were removed since we no longer
support legacy extensions and they added unneeded complexity to Firefox.


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

Re: PSA: Avoid Visual Studio 2017 15.7.0

[Frank-Rainer Grahl]

Make sure you also disable the autoupdate in the task scheduler!

"VSIX Auto Update 14 under Microsoft VisualStudio".

FRG

Ryan VanderMeulen wrote:

Yesterday, Microsoft released Visual Studio 2017 15.7.0. Unfortunately, it
is currently not usable for building Firefox due to bug 1458247 (internal
compiler errors in WebRTC code). The bug was already reported and confirmed
upstream during the 15.7 preview cycle, but unfortunately the final release
still shipped with the bug present.

At this point, there are no workarounds available for this issue, so avoid
the update if you want to be able to continue building Firefox.

-Ryan


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

Re: Fwd: Announcing the next Extended Support Release of Firefox - ESR60 with policy engine

[Frank-Rainer Grahl]

> Second, we will branch ESR from 60 instead of 59.
> This will give us more time to work on the Enterprise policies.
> Also, In parallel, this means that we will have more time to delete 
old/dead code before branching.
> As a disguised advertisement, I am using this email to remind that Marco 
Castelluccio's tool
> https://marco-c.github.io/code-coverage-reports/ is your best friend to 
find dead code [1].


It would be nice if you can check comm-central usage before removing larger 
bits or interfaces for ESR 60 e.g. web extensions support for mail is not ready.


Thanks
FRG



Sylvestre Ledru wrote:

Hello,

Earlier today, we announced on the enterprise ML several changes to ESR.

First, as Dave Camp mentioned during the Firefox All Hands, we are started some 
developments to improve
our support for enterprise users.
More information can be found on the wiki: 
https://wiki.mozilla.org/Firefox/EnterprisePolicies

Second, we will branch ESR from 60 instead of 59.
This will give us more time to work on the Enterprise policies.
Also, In parallel, this means that we will have more time to delete old/dead 
code before branching.
As a disguised advertisement, I am using this email to remind that Marco 
Castelluccio's tool
https://marco-c.github.io/code-coverage-reports/ is your best friend to find 
dead code [1].

Last but not least, we also warned our enterprise users that ESR52.9 (EOL 
August 28th) will be the last release supporting legacy add-ons.

The wiki and the ESR FAQ have been updated: 
https://wiki.mozilla.org/RapidRelease/Calendar
https://www.mozilla.org/en-US/firefox/organizations/faq/

Sylvestre

PS: Also, for people on these two MLs who are still using Windows XP, you'll 
get a few more weeks to update ;)

[1] meta bug https://bugzilla.mozilla.org/show_bug.cgi?id=1415819

 Forwarded Message 
Subject:Announcing the next Extended Support Release of Firefox - ESR60 
with policy engine
Date:   Wed, 20 Dec 2017 14:06:57 +0100
From:   Sylvestre Ledru 
To: enterpr...@mozilla.org 



The Firefox ESR (extended support release) is based on an official release of 
Firefox desktop for use by organizations including schools, universities, 
businesses and others who need extended support for mass deployments. Since 
Firefox 10, ESR has grown in popularity and many large organizations
rely on it to let their employees browse the Internet securely.

We want to make customization of Firefox deployments simpler for system 
administrators and we’re pleased to announce that our next ESR version, Firefox 
60, will include a policy engine that increases customization possibilities and 
integration into existing management systems.

What is the policy engine?
The Policy Engine is a project to build a Firefox desktop configuration and 
customization feature for enterprise users. The policy engine will work with 
any tool that wants to set policies and we intend to bring Windows Group Policy 
support soon. We’ll be initially supporting a limited set of
policies but this will be evolving through user feedback.
More details on the policy engine can be found here. 

Bug reference 

What’s the plan?
In order to accommodate the group policy implementation, we are making Firefox 
60 our next ESR version and will be following this plan:

   * May 8th - ESR 60.0 released (we’d love feedback from early adopters at 
that point and will be sharing a feedback form through the enterprise mailing 
list)
   * July 3rd - ESR 60.1 released
   * August 28th - End of life for ESR 52 and release of ESR 60.2.0. No further 
updates will be offered for ESR52 and an update to ESR60.0.2 will be provided 
through the application update service


Also please keep in mind that Firefox 57, released last month, supports only add-ons 
built with theWebExtensions API 
. This means that 
Firefox 52 ESR is the last release that will support legacy add-ons.  If you 
developed an add-on that has
not been updated to the WebExtensions API, there is still time to do so.Documentation 
is
 available, and you can ask questions by emailing dev-addons@mozilla.orgor joining 
the #webextensions channel
atirc.mozilla.org .
If you are supporting users who use add-ons, now is a good time to encourage them 
tocheck if their add-on works 
with
 Firefox 57+.

Erin, Felipe, Jeff, Kev, Mike Kaply, Romain, Shell & Sylvestre


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

Re: No more #ifdef MOZ_CRASHREPORTER directives needed when using crash reporter functions

[Frank-Rainer Grahl]

Hi,

I didn't see package-manifest changes in the bug.

I assume this needs to stay in as-is?

Thanks
FRG

+++ snip +++

; [Crash Reporter]
;
#ifdef MOZ_CRASHREPORTER
@RESPATH@/components/CrashService.manifest
@RESPATH@/components/CrashService.js
@RESPATH@/components/toolkit_crashservice.xpt
#ifdef XP_MACOSX
@BINPATH@/crashreporter.app/
#else
@BINPATH@/crashreporter@BIN_SUFFIX@
@RESPATH@/crashreporter.ini
@BINPATH@/minidump-analyzer@BIN_SUFFIX@
#ifdef XP_UNIX
@RESPATH@/Throbber-small.gif
#endif
#endif
@RESPATH@/browser/crashreporter-override.ini
#ifdef MOZ_CRASHREPORTER_INJECTOR
@BINPATH@/breakpadinjector.dll
#endif
#endif

Gabriele Svelto wrote:

[cross-posting to firefox-dev]

  Fellow mozillians,
bug 1402519 [1] just landed and it introduces a dummy implementation of
the crash reporter which is built when configuring with
--disable-crash-reporter. This removes the need for bracketing calls to
the crash reporter with #ifdef MOZ_CRASHREPORTER / #endif preprocessor
directives. You can now freely use the crash reporter methods without
worrying about it being enabled at compiler time or not.

I've also removed all the existing directives and only a few remain
where they are actually needed. JavaScript consumers should be
unaffected save for the following pattern which was used in a few places
to detect if the crash reporter had been compiled:

if ("nsICrashReporter" in Ci &&
 Services.appinfo instanceof Ci.nsICrashReporter) {
 // Crash reporter is enabled
}

This doesn't work anymore as the nsICrashReporter interface is always
present. You can replace it with:

if (AppConstants.MOZ_CRASHREPORTER) {
   // Crash reporter is enabled
}

This touched a lot of places in the code so if anything crash-related
seems wrong please let me know.

  Gabriele

[1] Use a dummy crashreporter implementation when building with
--disable-crashreporter
 https://bugzilla.mozilla.org/show_bug.cgi?id=1402519



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

Re: Proposal to remove the xpfe autocomplete bindings and the xpfe/components/autocomplete directory

[Frank-Rainer Grahl]

They are used in comm-central suite and owned by suite. We are currently 
evaluating moving them to comm-central. There is also corresponding css in the 
tree.


Regards
Frank-Rainer Grahl




Brian Grinstead wrote:

While tracking down the XBL bindings in the tree, I noticed that there are 4 
inside the xpfe/ directory at 
https://github.com/mozilla/gecko-dev/blob/master/xpfe/components/autocomplete/resources/content/autocomplete.xml.

I'd like to remove those bindings, and AFAICT we aren't using them in Firefox. 
Are there any objections to removing the code from m-c?

Thanks,
Brian


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

Re: Important changes to account security on bugzilla.mozilla.org

[Frank-Rainer Grahl]

Thanks for the clarification.

FRG

Daniel Veditz wrote:

On Fri, Sep 8, 2017 at 2:42 PM, Frank-Rainer Grahl <f...@gmx.com> wrote:


who can see confidential or secure bugs


This is a bit vague. If I am cced to a secure bug does this apply if I
only have editbugs otherwise?



​There's a missing ".. by default" there. Only applies if your account is a
member of a bugzilla "group" that controls bug access; BMO isn't going to
run queries to see if you happen to be CC'd on bugs every time you log in.
Note: ALL Mozilla employee accounts will be affected because all have
access to an internal employee group.

-
​Dan Veditz​


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

Re: Important changes to account security on bugzilla.mozilla.org

[Frank-Rainer Grahl]

> who can see confidential or secure bugs

This is a bit vague. If I am cced to a secure bug does this apply if I only 
have editbugs otherwise?


FRG

Dylan Hardison wrote:

As of September 18th, Mozilla employees and community members who can see 
confidential or secure bugs will be required to enable 2FA within 7 days of the 
next time they access BMO.

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

Removal of deprecated apis

[Frank-Rainer Grahl]

Great that you are so zealous to remove deprecated apis from the tree. I just 
wish I would see the same amount of work put into fixing web extensions 
shortcomings. Many classic add-ons already broken and new ones not available. 
had to fixup ABP myself to make it usable again but still prefer to stay on Beta.


The list did seem to have gotten a little longer in the last few days...

https://bugzilla.mozilla.org/buglist.cgi?component=WebExtensions%3A%20General=Toolkit_status=__open__

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

Re: Changing .idl files

[Frank-Rainer Grahl]

Just for reference. With latest NoScript View Source is broken and it throws 
an exception now and then. Still on Beta because of this one. I won't browse 
the web without it.


For me Web Extensions do not cut it yet and Classic Extensions are unsupported 
and go away. Bad timing even on a Nightly. You should have waited till ESR 59 
for mass removals of interfaces and to stabilize this more.


FRG

Boris Zbarsky wrote:

On 8/7/17 1:05 PM, Kris Maglione wrote:


So if right now we land a patch that breaks addons, and a nightly user 
updates, they get a broken browser and have to try to figure out whether it's 
because we broken an addon (and this may not be the first thing they think of) 
or because we introduced a bug that they should report.


So I strongly feel that to avoid wasting the time and effort of our nightly 
users we should not start landing addon-breaking changes (or at least ones 
that might cause exceptions in addons that break various browser 
functionality) until after we have disabled addons.


Note that the issues addon authors are having are precisely the "we don't want 
to make nightly users' lives hell, so we're trying to make sure our addons 
keep working for the users who have them installed" issue.  As in, they're 
caring more about our nightly users a lot more than some of our developers 
seem to be.  :(


If people just want to clean up IDL, which is what I'm seeing, they should 
start with the ton of noscript interfaces we have that need cleanup and which 
are known to not break any addons ever since we remove binary addon support.


-Boris

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

Re: removing "the old way" of signing add-ons

[Frank-Rainer Grahl]

I need to look at the notifications for SeaMonkey anyway but how could 
Thunderbird implement the standard doorhanger with no location bar? I 
think the dialog should be retained for projects which do not have a 
location bar and/or tabbrowser.


FRG

Onno Ekker wrote:

Op 7/23/2017 om 2:12 AM schreef Andrew Swan:

On Fri, Jul 21, 2017 at 12:32 AM, Jörg Knobloch  wrote:


Since you're saying that we're still using the old interface, in fact
Andrew said: "old add-on install
confirmation dialog, that dialog includes a note about the certificate",
would you be able to give us some exact DXR references which would save us
a lot of searching.



The dialog I mentioned is:
https://dxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/content/xpinstallConfirm.xul

The listbox in that dialog holds instances of:
https://dxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/content/xpinstallItem.xml

The label in those items with the class "xpinstallItemSigned" ends up
holding either certificate details or some default message like "Author not
verified"

While we're on the topic, Thunderbird and Seamonkey should look at moving
over to the doorhanger addon install flow that Firefox uses -- that xul
dialog and everything that supports it are unused in Firefox and its days
are numbered.

-Andrew



Looks like this indeed still used by both Thunderbird and SeaMonkey:
http://i.imgur.com/Q7tQIsN.png (sorry for the Dutch screenshot).
I've also verified with DOM Inspector, that this is indeed above
mentioned dialog window.

Onno



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

Re: Announcing MozillaBuild 3.0 Release

[Frank-Rainer Grahl]

> This means some people on older hardware or OSes aren't able build Firefox,
This currently means that about 50% of the current users are not being able to 
build in the future. With Win 7 and 8.1 market share together we are not 
speaking about Vista here. I am building in a vm anyway so can set up a Win 10 
one too but limiting choices to force using an operating system which treats 
its users like dirt is not what I would call a good move. So as long as the 
compilers are supported on other OS than 10 I strongly disagree with this.

FRG

Mike Hoye wrote:

On 2017-07-22 3:13 AM, Frank-Rainer Grahl wrote:
Personally I find this a bad idea. Windows 7 and 8.1 are still supported 
till 2020 and 2023. As long as the compilers are supported too on them these 
should also be fully supported as a build environment. 
Unfortunately we have to build _for_ a number of our supported operating 
systems without being able to build _on_ those operating systems. That's been 
true for some time now; while we still support 32-bit systems, for example, 
you can't build Firefox on 32-bit systems at all due to memory constraints, 
and the new MozillaBuild system is 64-bit only due to a variety of dependencies.


This means some people on older hardware or OSes aren't able build Firefox, 
that's true, but it doesn't mean they have no way to contribute to Firefox, 
and restricting ourselves to only shipping a product that we can build 
directly on those older systems means giving every single person who relies on 
those systems a crap experience and a substandard product.


It'd be nice in some abstract sense to be able to bootstrap a Firefox 
executable on every system we support, but the tradeoffs we'd need to accept 
to do that (support costs, development velocity, actual as-delivered product 
quality and a lot more) are _so_ egregiously bad for everyone involved that 
there's no reasonable, much less responsible, way we can invest any time or 
effort making that happen.




- mhoye


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

Re: Announcing MozillaBuild 3.0 Release

[Frank-Rainer Grahl]

Personally I find this a bad idea. Windows 7 and 8.1 are still supported till 
2020 and 2023. As long as the compilers are supported too on them these should 
also be fully supported as a build environment. Windows 10 is buggy and worse 
than 8.1 in many aspects.  I usually do not wear a tin head but the data 
siphoning Microsoft is doing and which can't be disabled on non enterprise 
versions together with the other "features" like forced updates of the OS 
every once in a while makes it unsuiteable for my use. I could have smashed 
something when after a Windows 10 Pro install 8 GB of useless game demos where 
downloaded and presented to me. And that is not the only example. I never 
thought I would prefer 8.1 over anything but this is currently the case. Not 
sure what I do after 2023 but probably switch to Linux and run anything I need 
Windows for in a vm.

FRG

Gregory Szorc wrote:

Thanks for all your work on this, Ryan!

So everyone knows, this is hopefully the last major overhaul of
MozillaBuild.

The plan from build system land is to attempt to go "all in" on Windows
Subsystem for Linux (WSL). That's the feature in Windows 10 (and even in
Server additions now) that implements Linux syscalls inside the Windows
kernel and allows you to run Linux binaries "natively" on Windows. The
performance is pretty good and it is a better Linux-on-Windows approach
than msys ever will be. Assuming we can pull it off, the goal is to ditch
MozillaBuild and support building Firefox from WSL. You'll then be able to
develop on Windows from the comfort of a Linux command line with access to
the full power of your favorite Linux distro. We will likely maintain some
support for building in non-WSL environments for automation, etc. But for
the average developer, we want to focus on WSL because we perceive that to
be the best opportunity for a more pleasant development experience on
Windows.






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

Re: removing "the old way" of signing add-ons

[Frank-Rainer Grahl]

I know but I don't see any comm-central code which calls the apis in 
question directly or uses the return values. I just searched via dxr but 
would probably take a deeper look at the code to understand it. Might 
not matter anyway in the short time. With the destruction of the classic 
add-on infrastructure in Gecko 57 we need to port web extension support 
first anyway which will take some time. So just another task imho.


FRG

Kris Maglione wrote:

On Thu, Jul 20, 2017 at 10:32:27AM +0200, Frank-Rainer Grahl wrote:

Given all this, the question is do we still need this second API? Does
Thunderbird or SeaMonkey use it for any reason, or can we simplify the
code-base, reduce build size, etc.?


I looked at the code and don't see any use outside of toolkit. Same 
for the PREF_CUSTOM_CONFIRMATION_UI/"xpinstall.customConfirmationUI" 
pref. Seems to be only used in browser.


Please see replies elsewhere in this thread. Seamonkey and Thunderbird 
do use the old signature code that we're talking about removing.


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

Re: removing "the old way" of signing add-ons

[Frank-Rainer Grahl]

Given all this, the question is do we still need this second API? Does
Thunderbird or SeaMonkey use it for any reason, or can we simplify the
code-base, reduce build size, etc.?


I looked at the code and don't see any use outside of toolkit. Same for 
the PREF_CUSTOM_CONFIRMATION_UI/"xpinstall.customConfirmationUI" pref. 
Seems to be only used in browser.


FRG


Frank-Rainer Grahl wrote:
SeaMonkey does not use signing and does not plan to do so. It is 
disabled in the mozconfigs during build time in all trees with:


 > # Disable checking that add-ons are signed by the trusted root
 > MOZ_ADDON_SIGNING=0
 > # Disable enforcing that add-ons are signed by the trusted root
 > MOZ_REQUIRE_SIGNING=0

So I think we don't have a problem here if something gets changed and 
the toolkit code still honors these.


As far as I know Thunderbird does the same.

FRG

David Keeler wrote:

[dev-apps-thunderbird and dev-apps-seamonkey cc'd, but please discuss on
dev-platform]

Hello Everyone,

You may or may not be surprised to learn that Gecko contains two
different ways to verify that an add-on has been signed. The primary
method is nsIX509CertDB.openSignedAppFileAsync. This is what Gecko-based
products that require add-on signing use. However, there is also
nsIZipRreader.getSigningCert (plus some additional glue code).

The only place where these two implementations share code is in the
actual signature verification. That is, the logic to ensure that every
file in the archive has a corresponding valid entry in the manifest (and
that every entry in the manifest has a corresponding file in the
archive) and so on appears in Gecko twice.

 From what I can tell, the actual functionality provided by the second
API (which is only applicable in builds that do not require add-on
signing) is a small text label in the install dialog that identifies the
certificate that signed the add-on. Note that this isn't even the dialog
that Firefox uses by default - you have to flip
"xpinstall.customConfirmationUI" to false to see it. In the default
dialog in Firefox, there is no difference between an unsigned add-on and
an add-on signed by a non-Mozilla root certificate that has been trusted
for code signing (and note that soon no certificate in Mozilla's root CA
program will have the code signing trust bit enabled by default [0])
(and again, this only applies to builds where add-on signing isn't
required - for builds where it is required, this API is not used at all).

Given all this, the question is do we still need this second API? Does
Thunderbird or SeaMonkey use it for any reason, or can we simplify the
code-base, reduce build size, etc.?

Cheers,
David

[0] https://bugzilla.mozilla.org/show_bug.cgi?id=1366243





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

Re: removing "the old way" of signing add-ons

[Frank-Rainer Grahl]

SeaMonkey does not use signing and does not plan to do so. It is 
disabled in the mozconfigs during build time in all trees with:


> # Disable checking that add-ons are signed by the trusted root
> MOZ_ADDON_SIGNING=0
> # Disable enforcing that add-ons are signed by the trusted root
> MOZ_REQUIRE_SIGNING=0

So I think we don't have a problem here if something gets changed and 
the toolkit code still honors these.


As far as I know Thunderbird does the same.

FRG

David Keeler wrote:

[dev-apps-thunderbird and dev-apps-seamonkey cc'd, but please discuss on
dev-platform]

Hello Everyone,

You may or may not be surprised to learn that Gecko contains two
different ways to verify that an add-on has been signed. The primary
method is nsIX509CertDB.openSignedAppFileAsync. This is what Gecko-based
products that require add-on signing use. However, there is also
nsIZipRreader.getSigningCert (plus some additional glue code).

The only place where these two implementations share code is in the
actual signature verification. That is, the logic to ensure that every
file in the archive has a corresponding valid entry in the manifest (and
that every entry in the manifest has a corresponding file in the
archive) and so on appears in Gecko twice.

 From what I can tell, the actual functionality provided by the second
API (which is only applicable in builds that do not require add-on
signing) is a small text label in the install dialog that identifies the
certificate that signed the add-on. Note that this isn't even the dialog
that Firefox uses by default - you have to flip
"xpinstall.customConfirmationUI" to false to see it. In the default
dialog in Firefox, there is no difference between an unsigned add-on and
an add-on signed by a non-Mozilla root certificate that has been trusted
for code signing (and note that soon no certificate in Mozilla's root CA
program will have the code signing trust bit enabled by default [0])
(and again, this only applies to builds where add-on signing isn't
required - for builds where it is required, this API is not used at all).

Given all this, the question is do we still need this second API? Does
Thunderbird or SeaMonkey use it for any reason, or can we simplify the
code-base, reduce build size, etc.?

Cheers,
David

[0] https://bugzilla.mozilla.org/show_bug.cgi?id=1366243



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

Re: Intent to unship: tree pseudo-element selectors from web content (::-moz-tree-*)

[Frank-Rainer Grahl]

Sure but I mean Remote XUL as in here:

https://docs.oracle.com/cd/E60665_01/pbcs_common/CSPGS/ch01s05s03s01.html

https://addons.mozilla.org/en-US/firefox/addon/remote-xul-manager/
FRG

Xidorn Quan wrote:

On Fri, Jul 7, 2017, at 03:55 PM, Frank-Rainer Grahl wrote:

Not using it but will this break remote XUL?


XUL shouldn't be usable in content at all. Chrome document which have
access to XUL should not be affected.

- Xidorn



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

Re: Intent to unship: tree pseudo-element selectors from web content (::-moz-tree-*)

[Frank-Rainer Grahl]

Not using it but will this break remote XUL?

FRG

Xidorn Quan wrote:

I intent to unship tree pseudo-element selectors from web content in bug
1379031 [1].

This includes the following pseudo-elements:
::-moz-tree-column
::-moz-tree-row
::-moz-tree-separator
::-moz-tree-cell
::-moz-tree-indentation
::-moz-tree-line
::-moz-tree-twisty
::-moz-tree-image
::-moz-tree-cell-text
::-moz-tree-checkbox
::-moz-tree-progressmeter
::-moz-tree-drop-feedback

They are used for matching anonymous boxes generated for some XUL
elements. Since XUL is not accessible from web content, it makes little
sense to support these selectors there. These selectors will still be
available to chrome documents.

Although they don't currently match anything on web content, there is
still some risk for unshipping them. Specifically, some websites seem to
use them for browser-sniffing.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1379031


- Xidorn



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

Re: Tracking bug for removals after XPCOM extensions are no more?

[Frank-Rainer Grahl]

Firefox will probably loose enough usera already because of the webextensions 
only policy so you might rather add something to the api instead of taking 
things away. If its a useful api someone will use it when writing extensions.


FRG

Benjamin Smedberg wrote:

On Wed, Mar 15, 2017 at 4:24 PM, Boris Zbarsky  wrote:


On 3/15/17 3:26 PM, Botond Ballo wrote:


What will happen to WebExtension Experiments once these APIs start
being removed? My understanding is that WebExtension Experiments use
the same XPCOM APIs as XUL addons.



We shouldn't be removing APIs that have no alternative.



As a blanket statement, I don't understand what this means.

I am thinking the exact opposite sentiment: after Firefox 57 when
Webextensions are the only extensions, if our product no longer needs some
functionality (and it's "API"), let's remove it. Quickly and ruthlessly. We
need to actively work to maintain less code.

Do we disagree, or do I misunderstand?

--BDS



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

Re: The future of commit access policy for core Firefox

[Frank-Rainer Grahl]

Ehsan Akhgari wrote:

Even with a single reviewer, I often times end up making some trivial
changes to my patches to fix stupid mistakes and issues that I know the
reviewer doesn't care enough to want to look at before landing.  In
general our code review process has a lot of flexibility built into it,
and reviewers generally understand that the goal ultimately is to ensure
the quality of the produced code, so depending on the circumstances as a
reviewer I can treat a patch on different levels of scrutiny, from
anywhere between checking the actual landed patch and complaining if
something wasn't done in the way I asked to r+ing asking for a lot of
changes and trusting the author will do the right thing without needing
me look over their work more.

...

Same here. Automation is fine if everything goes according to plan but pushing 
manually is much less time consuming if something goes wrong e.g. a patch 
needs trivial changes to un-bitrot it. So there should still be a way to just 
push manually if needed or desired.


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

Re: The future of commit access policy for core Firefox

[Frank-Rainer Grahl]

Me too. Have a phone which does what I need (calling people and be called:) ) 
No need for a mobile device which has its own security and usability problems.


FRG

Masatoshi Kimura wrote:

On 2017/03/10 6:53, Mike Connor wrote:

- Two-factor auth must be a requirement for all users approving or
pushing a change.


I have no mobile devices. How can I use 2FA?

Previously I was suggested to buy a new PC and SSD only to shorten the
build time. Now do I have to buy a smartphone only to contribute
Mozilla? What's the next?




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