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
> 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
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
> 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
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
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
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 m
> 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
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
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
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
ank-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 operat
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
-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
/"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
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
>
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
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
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,
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
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
21 matches
Mail list logo
