Re: Intent to remove: Fennec

[mark . erikson]

Haha :)  I both appreciate the "request to get involved" aspect, as well as the 
subtle "STOP WHINING AND CONTRIBUTE SOMETHING USEFUL!" aspect... I've repeated 
that phrase more times than I can count myself :)

I actually am a maintainer of the Redux JS state management lib, so A) that 
already sucks up all my free time, and B) I'm mostly a JS and Python dev, and 
while I've done Java in the past, it's not my strong point (and really I'd 
rather not ever write Java again if I don't have to).

On Tuesday, September 24, 2019 at 9:12:08 PM UTC-4, Jared Hirsch wrote:
> Hey Mark,
> 
> Since you've traveled this far down the rabbit hole already, seems like I
> should just _casually mention_ that contributions are welcome ^_^
> 
> You can learn about Mozilla's next-gen Android browsers and browser
> components here, if you're interested:
> 
> https://mozac.org/contributing/
> https://mozac.org/blog/
> https://github.com/mozilla-mobile/fenix
> https://github.com/mozilla-mobile/android-components
> 
> If Android hacking isn't your thing, the contributor docs on MDN can help
> you explore other projects:
> 
> https://developer.mozilla.org/docs/Mozilla/Developer_guide
> 
> Feel free to ping me, too, with any questions.
> 
> Have fun!
> 
> Jared
> 
> On Tue, Sep 24, 2019 at 11:45 AM  wrote:
> 
> > Yeah, this kind of detail was really missing from the public statements
> > :)  I don't expect consumer-facing PR posts to go into nitty-gritty
> > technical details, but it wasn't apparent that there was really anything
> > more going on besides "nope, we're just going to rewrite it and move all
> > the UI around in the process".  Appreciate the info.
> >
> > On Tuesday, September 24, 2019 at 1:41:44 PM UTC-4, Kris Maglione wrote:
> > > On Tue, Sep 24, 2019 at 10:07:28AM -0700, mark.erik...@gmail.com wrote:
> > > >- I am very happy with the current Fennec app and its UI, and
> > > >don't understand why Mozilla feels a need to drop that product
> > > >and create a new one from scratch.
> > >
> > > We're not creating a new one from scratch. Many of the component
> > > parts of Fenix already existed, and the core is basically the
> > > same as Fennec. That said, there are many reasons:
> > >
> > > 1) GeckoView, which is a more or less drop-in replacement for
> > > Android's WebView, is designed to be used by any application
> > > which needs to embed web content on Android, including
> > > potentially other web browsers. It's an important part of our
> > > core mission to make sure the web remains a viable living
> > > standard, with multiple competing implementations, to avoid the
> > > sort of stagnation and vendor lock-in we saw when IE6
> > > essentially ruled the world.
> > >
> > > 2) We also already needed to maintain WebView-based browser
> > > front-ends for configurations where shipping our entire
> > > rendering back-end was not viable or practical. Given that we
> > > already need to maintain these separate, already-compatible
> > > front-end and back-end implementations, having to maintain an
> > > entirely separate browser with a completely different front-end,
> > > and a lot of different back-end glue, is just not a good use of
> > > resources.
> > >
> > > 3) GeckoView and the Fenix front-end are much more modern
> > > frameworks than Fennec. They were architected from the ground up
> > > using all of the knowledge and experience that we've gained
> > > developing Fennec and a number of other experimental browsers
> > > over the years. The result is that they are not only much easier
> > > to develop and maintain, but also much faster and more resource
> > > efficient.
> > >
> > > 4) The current Fennec browser, unlike Fenix and our desktop
> > > browsers, is very much single-process by design. Web content
> > > runs in the same process as the browser UI. The native Java UI
> > > allows us to use threading to work around some of the
> > > performance problems inherent in this sort of design, but it
> > > doesn't give us any of the security properties of process
> > > isolation, which are becoming increasingly important in the age
> > > of Spectre attacks. If we wanted to continue maintaining Fennec
> > > apart from Fenix, we would need to drastically rearchitect it to
> > > support process isolation for web content. And, given that
> > > Fenix and GeckoView were designed to handle this from the start,
> > > again, that would just not be a good use of resources.
> > >
> > > --
> > > Kris Maglione
> > >
> > > UNIX is simple.  It just takes a genius to understand its simplicity.
> > >   --Dennis Ritchie
> >
> > ___
> > 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 remove: Fennec

[Jared Hirsch]

Hey Mark,

Since you've traveled this far down the rabbit hole already, seems like I
should just _casually mention_ that contributions are welcome ^_^

You can learn about Mozilla's next-gen Android browsers and browser
components here, if you're interested:

https://mozac.org/contributing/
https://mozac.org/blog/
https://github.com/mozilla-mobile/fenix
https://github.com/mozilla-mobile/android-components

If Android hacking isn't your thing, the contributor docs on MDN can help
you explore other projects:

https://developer.mozilla.org/docs/Mozilla/Developer_guide

Feel free to ping me, too, with any questions.

Have fun!

Jared

On Tue, Sep 24, 2019 at 11:45 AM  wrote:

> Yeah, this kind of detail was really missing from the public statements
> :)  I don't expect consumer-facing PR posts to go into nitty-gritty
> technical details, but it wasn't apparent that there was really anything
> more going on besides "nope, we're just going to rewrite it and move all
> the UI around in the process".  Appreciate the info.
>
> On Tuesday, September 24, 2019 at 1:41:44 PM UTC-4, Kris Maglione wrote:
> > On Tue, Sep 24, 2019 at 10:07:28AM -0700, mark.erik...@gmail.com wrote:
> > >- I am very happy with the current Fennec app and its UI, and
> > >don't understand why Mozilla feels a need to drop that product
> > >and create a new one from scratch.
> >
> > We're not creating a new one from scratch. Many of the component
> > parts of Fenix already existed, and the core is basically the
> > same as Fennec. That said, there are many reasons:
> >
> > 1) GeckoView, which is a more or less drop-in replacement for
> > Android's WebView, is designed to be used by any application
> > which needs to embed web content on Android, including
> > potentially other web browsers. It's an important part of our
> > core mission to make sure the web remains a viable living
> > standard, with multiple competing implementations, to avoid the
> > sort of stagnation and vendor lock-in we saw when IE6
> > essentially ruled the world.
> >
> > 2) We also already needed to maintain WebView-based browser
> > front-ends for configurations where shipping our entire
> > rendering back-end was not viable or practical. Given that we
> > already need to maintain these separate, already-compatible
> > front-end and back-end implementations, having to maintain an
> > entirely separate browser with a completely different front-end,
> > and a lot of different back-end glue, is just not a good use of
> > resources.
> >
> > 3) GeckoView and the Fenix front-end are much more modern
> > frameworks than Fennec. They were architected from the ground up
> > using all of the knowledge and experience that we've gained
> > developing Fennec and a number of other experimental browsers
> > over the years. The result is that they are not only much easier
> > to develop and maintain, but also much faster and more resource
> > efficient.
> >
> > 4) The current Fennec browser, unlike Fenix and our desktop
> > browsers, is very much single-process by design. Web content
> > runs in the same process as the browser UI. The native Java UI
> > allows us to use threading to work around some of the
> > performance problems inherent in this sort of design, but it
> > doesn't give us any of the security properties of process
> > isolation, which are becoming increasingly important in the age
> > of Spectre attacks. If we wanted to continue maintaining Fennec
> > apart from Fenix, we would need to drastically rearchitect it to
> > support process isolation for web content. And, given that
> > Fenix and GeckoView were designed to handle this from the start,
> > again, that would just not be a good use of resources.
> >
> > --
> > Kris Maglione
> >
> > UNIX is simple.  It just takes a genius to understand its simplicity.
> >   --Dennis Ritchie
>
> ___
> 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

Of writing asynchronous tests

[smaug]

Hi all,

during the past year, while optimizing page load by changing how various tasks 
within Gecko are scheduled,
intermittently failing tests have often caused trouble and required fixes to 
them or occasionally
disabling them. Now with Fission we are seeing even more issues and we will do 
page load optimizations on top of
Fission, and that will probably reveal yet more issues.

A somewhat old page 
https://developer.mozilla.org/en-US/docs/Mozilla/QA/Avoiding_intermittent_oranges
 has still a pretty good list
of common pitfalls. I recommend everyone writing asynchronous tests to take a 
look at that
(and possibly add more cases there, if you think the page is missing something).

This is not to blame anyone - writing asynchronous tests can be hard. I 
certainly have been fixing recently tests written by myself ;)
But I'm hoping that we can improve the quality of the tests over the time and 
thus make it easier to make changes to Gecko's
task and/or process scheduling.


Thanks,



-Olli

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

Re: Intent to remove: Fennec

[mark . erikson]

Yeah, this kind of detail was really missing from the public statements :)  I 
don't expect consumer-facing PR posts to go into nitty-gritty technical 
details, but it wasn't apparent that there was really anything more going on 
besides "nope, we're just going to rewrite it and move all the UI around in the 
process".  Appreciate the info.

On Tuesday, September 24, 2019 at 1:41:44 PM UTC-4, Kris Maglione wrote:
> On Tue, Sep 24, 2019 at 10:07:28AM -0700, mark.erik...@gmail.com wrote:
> >- I am very happy with the current Fennec app and its UI, and 
> >don't understand why Mozilla feels a need to drop that product 
> >and create a new one from scratch.
> 
> We're not creating a new one from scratch. Many of the component 
> parts of Fenix already existed, and the core is basically the 
> same as Fennec. That said, there are many reasons:
> 
> 1) GeckoView, which is a more or less drop-in replacement for 
> Android's WebView, is designed to be used by any application 
> which needs to embed web content on Android, including 
> potentially other web browsers. It's an important part of our 
> core mission to make sure the web remains a viable living 
> standard, with multiple competing implementations, to avoid the 
> sort of stagnation and vendor lock-in we saw when IE6 
> essentially ruled the world.
> 
> 2) We also already needed to maintain WebView-based browser 
> front-ends for configurations where shipping our entire 
> rendering back-end was not viable or practical. Given that we 
> already need to maintain these separate, already-compatible 
> front-end and back-end implementations, having to maintain an 
> entirely separate browser with a completely different front-end, 
> and a lot of different back-end glue, is just not a good use of 
> resources.
> 
> 3) GeckoView and the Fenix front-end are much more modern 
> frameworks than Fennec. They were architected from the ground up 
> using all of the knowledge and experience that we've gained 
> developing Fennec and a number of other experimental browsers 
> over the years. The result is that they are not only much easier 
> to develop and maintain, but also much faster and more resource 
> efficient.
> 
> 4) The current Fennec browser, unlike Fenix and our desktop 
> browsers, is very much single-process by design. Web content 
> runs in the same process as the browser UI. The native Java UI 
> allows us to use threading to work around some of the 
> performance problems inherent in this sort of design, but it 
> doesn't give us any of the security properties of process 
> isolation, which are becoming increasingly important in the age 
> of Spectre attacks. If we wanted to continue maintaining Fennec 
> apart from Fenix, we would need to drastically rearchitect it to 
> support process isolation for web content. And, given that 
> Fenix and GeckoView were designed to handle this from the start, 
> again, that would just not be a good use of resources.
> 
> -- 
> Kris Maglione
> 
> UNIX is simple.  It just takes a genius to understand its simplicity.
>   --Dennis Ritchie

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

Re: Intent to remove: Fennec

[Botond Ballo]

On Tue, Sep 24, 2019 at 1:10 PM  wrote:
> - I have a _bunch_ of addons installed in Fennec.  uBlock Origin is by far 
> the most critical, but I have a number of other quality-of-life addons as 
> well.  Based on the articles I've seen, Fenix does not yet have any extension 
> support, so I can't even justify trying it out.

Note that this "intent to remove" email refers only to removing Fennec
code from our mainline development branch. It does not mean stopping
to ship Fennec right away. Fennec continues to be shipped from our ESR
68 branch, and will continue to do so until Fenix is considered ready
to replace it. My understanding is, extension support will definitely
be part of that.

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

Re: Intent to remove: Fennec

[Kris Maglione]

On Tue, Sep 24, 2019 at 10:07:28AM -0700, mark.erik...@gmail.com wrote:
- I am very happy with the current Fennec app and its UI, and 
don't understand why Mozilla feels a need to drop that product 
and create a new one from scratch.


We're not creating a new one from scratch. Many of the component 
parts of Fenix already existed, and the core is basically the 
same as Fennec. That said, there are many reasons:


1) GeckoView, which is a more or less drop-in replacement for 
Android's WebView, is designed to be used by any application 
which needs to embed web content on Android, including 
potentially other web browsers. It's an important part of our 
core mission to make sure the web remains a viable living 
standard, with multiple competing implementations, to avoid the 
sort of stagnation and vendor lock-in we saw when IE6 
essentially ruled the world.


2) We also already needed to maintain WebView-based browser 
front-ends for configurations where shipping our entire 
rendering back-end was not viable or practical. Given that we 
already need to maintain these separate, already-compatible 
front-end and back-end implementations, having to maintain an 
entirely separate browser with a completely different front-end, 
and a lot of different back-end glue, is just not a good use of 
resources.


3) GeckoView and the Fenix front-end are much more modern 
frameworks than Fennec. They were architected from the ground up 
using all of the knowledge and experience that we've gained 
developing Fennec and a number of other experimental browsers 
over the years. The result is that they are not only much easier 
to develop and maintain, but also much faster and more resource 
efficient.


4) The current Fennec browser, unlike Fenix and our desktop 
browsers, is very much single-process by design. Web content 
runs in the same process as the browser UI. The native Java UI 
allows us to use threading to work around some of the 
performance problems inherent in this sort of design, but it 
doesn't give us any of the security properties of process 
isolation, which are becoming increasingly important in the age 
of Spectre attacks. If we wanted to continue maintaining Fennec 
apart from Fenix, we would need to drastically rearchitect it to 
support process isolation for web content. And, given that 
Fenix and GeckoView were designed to handle this from the start, 
again, that would just not be a good use of resources.


--
Kris Maglione

UNIX is simple.  It just takes a genius to understand its simplicity.
--Dennis Ritchie

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

Web IDL now uses mixin syntax, not "implements"

[Boris Zbarsky]

The way mixins are done in IDL has changed syntax somewhat.  Instead of 
having a [NoInterfaceObject] interface and an "implements" statement, 
the new setup looks like this:


  interface A {};

  interface mixin B {
void somethingMixedIn();
  }

  A includes B;

In-tree IDL has been updated to the new syntax.  Support for the old 
syntax has not been removed yet, but will be as soon as that patch is 
reviewed; please do not add new IDL using "implements".


The new setup is a little less featureful: mixins have no inheritance 
and cannot include other mixins.  They _do_ support partials, so you can do:


  interface A {};
  interface mixin B {};
  partial interface mixin B {
void somethingMixedIn();
  };
  A includes B;

A mixin and its partials have to in the same .webidl file, just like our 
existing rules for interfaces.  This is not enforced yet, but will be 
soon.  Similarly, the "A includes B" statement must be in the same 
.webidl file as the definition of interface A.  This part _is_ enforced.


Mixins have somewhat restricted syntax compared to interfaces (e.g. do 
not allow mixing in constructors, getter/setter operations, iterable 
declarations, etc).  This should not be a problem in practice, and 
certainly wasn't for anything we had in-tree.


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

Re: Intent to remove: Fennec

[mark . erikson]

Heh.  No, I haven't tried Fenix, which I realize also makes it a bit harder to 
take my complaints seriously :)

Having said that:

- I am very happy with the current Fennec app and its UI, and don't understand 
why Mozilla feels a need to drop that product and create a new one from 
scratch.  I know there's mentions of a "GeckoView" piece that sounds like it 
makes embedding easier, but I don't know why that can't be plugged into the 
existing Fenix codebase.
- I have a _bunch_ of addons installed in Fennec.  uBlock Origin is by far the 
most critical, but I have a number of other quality-of-life addons as well.  
Based on the articles I've seen, Fenix does not yet have any extension support, 
so I can't even justify trying it out.

There was a long HN discussion thread at 
https://news.ycombinator.com/item?id=20295694 a few months ago, which has a 
number of criticisms of this migration process.  I would generally agree with 
the criticisms in that thread, regarding Fenix vs Fennec, and general Mozilla 
priorities.  Given Mozilla's long-declining market share, throwing resources 
into rewriting the Android app for no obvious benefit seems like a waste, vs 
improving the desktop app further.

On Tuesday, September 24, 2019 at 3:47:13 AM UTC-4, Dirkjan Ochtman wrote:
> On Mon, Sep 23, 2019 at 10:51 PM  wrote:
> 
> > As a happy Fennec end user with no direct involvement with Mozilla, I'm
> > decidedly unhappy about the direction Mozilla seems to be going here.  I
> > don't expect this complaint to have any effect on plans, but FYI.
> >
> 
> Have you actually tried Fenix (Firefox Preview)? How did it fall short of
> your usage of Fennec?
> 
> Kind regards,
> 
> Dirkjan

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

Implemented nsIConsoleService::logMessage logging from parent to content process

[Paul Zühlcke]

Hi everyone!

I've landed a patch enabling nsIConsoleService::logMessage to log script
errors from parent to content process.

For example, this enables JavaScript logging from the parent process to the
website console. Simply initialize the script error with a window ID:

let consoleMsg =
Cc["@mozilla.org/scripterror;1"].createInstance(Ci.nsIScriptError);let
windowId = gBrowser.selectedBrowser.innerWindowID;let message =
"Hello, World!";
consoleMsg.initWithWindowID(message, gBrowser.currentURI.spec, null, 0, 0,
Ci.nsIScriptError.warningFlag, "MyCategory",
 windowId);

Services.console.logMessage(consoleMsg);


The bug tracking this: https://bugzilla.mozilla.org/show_bug.cgi?id=1559167

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

Re: Intent to remove: Fennec

[Bobby Holley]

+1. This is a big milestone, and reflects countless hours of hard work
building our next-generation mobile stack. Congrats to everyone
involved!

On Thu, Sep 19, 2019 at 12:59 PM Kris Maglione  wrote:
>
> This sounds like a stellar plan.
>
> -Kris
>
> On Thu, Sep 19, 2019 at 02:55:56PM -0500, James Willcox wrote:
> >Folks,
> >
> >As you may be aware, Fennec has been frozen on 68 ESR with the expectation
> >that Fenix will become the new Firefox for Android in 2020. For reasons of
> >hygiene and simplification, I propose that we begin removing Fennec from
> >mozilla-central as soon as feasible. There are a few known blockers
> >currently being tracked under bug 1582218. If you know of any other issues,
> >please let me know and/or file blockers.
> >
> >Obviously, we will not be removing anything related to GeckoView. This
> >means that mobile/android/geckoview/, MOZ_WIDGET_ANDROID, etc. will all be
> >sticking around. Only the Fennec frontend and any platform code that needed
> >to disambiguate Fennec from GeckoView at runtime[0] will be targeted.
> >
> >Thanks,
> >James
>
> --
> Kris Maglione
>
> Of all the preposterous assumptions of humanity over humanity, nothing
> exceeds most of the criticisms made on the habits of the poor by the
> well-housed, well-warmed, and well-fed.
> --Herman Melville
>
> ___
> 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

Moving Firefox to a faster 4-week release cycle!

[Ritu Kothari]

We’re excited to announce

that we’re adjusting Firefox release cadence to increase our agility, and
to bring you new features more quickly. Starting Q1 2020, we plan to ship a
major Firefox release every 4 weeks.

Shorter release cycles provide greater flexibility to support product
planning and priority changes due to business or market requirements. It
allows us to be more agile and ship features faster while applying the same
rigor and due diligence needed to ship a high-quality and stable release. Major
updates to ESR (Extended Support Release
 for the enterprise)
will remain yearly, as they do now. There will be a 3 months support
overlap between new ESR and end-of-life of previous ESR version. The next
two major ESR releases will be ~June 2020 and ~June 2021. This change will
be deployed gradually starting with Fx71, achieving 4 week release cadence
by Q1 2020. You can refer to
https://wiki.mozilla.org/Release_Management/Calendar for the latest release
dates and other  information.

As we slowly reduce our release cycle length, from 7 weeks down to 6, 5, 4
weeks, there will be close monitoring of aspects like release scope change;
developer productivity impact (tree closure, build failures); beta code
churn (uplifts, new regressions); overall release stabilization and quality
(stability, performance, carryover regressions). Our main goal is to
identify bottlenecks that prevent us from being more agile in our release
cadence. Appropriate mitigations will be put in place should our metrics
highlight an unexpected trend.

If you have any questions or concerns, please email release-m...@mozilla.com


Thanks,

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

Re: Bugzilla posting failure.

[Emma Humphries]

Moving dev-platform to bcc.

Thank you for your email.

You had posted a bug, https://bugzilla.mozilla.org/show_bug.cgi?id=1574787,
which was resolved as a duplicate of
https://bugzilla.mozilla.org/show_bug.cgi?id=1472757, so that would not
show up in My Dashboard.

I'll ask the BMO team to see if they can can find the error logged from
this most recent incident where you tried to create an attachment, got an
error message, but the attachment had been created.

For future reference, the best place to file bugs related to creating bugs
is
https://bugzilla.mozilla.org/enter_bug.cgi?product=bugzilla.mozilla.org=Bug+Creation%2FEditing
.

E C Humphries, Bugmaster


On Mon, Sep 23, 2019 at 8:10 PM ishikawa  wrote:

> Hi,
>
> Where is the proper forum to post a bug regarding bugzilla.mozilla.org?
>
> I *THINK* I posted a bug regarding bugzilla failure a couple of months ago,
> but for some reason, I could not find it in "My Dashboard" and so I am
> posting the question here.
>
> I experienced a bugzilla problem today and it resulted in a pair of
> duplicated entry.
> Problem was that
> - bugzilla showed a message after initial posting that an attachment could
> not be uploaded or something ( I wish I had recorded the message), but
> - then I realize that after I added an attachment to the
>   resulting page WITHOUT attachment that a complete entry had already been
> created ...
>
> 1. Completely entry created despite the confusing error(?) message from
> bugzilla.
> https://bugzilla.mozilla.org/show_bug.cgi?id=1583415
>
> 2. After I clear the error message, I got a link to the following entry
> that
> lacked the attachment, and so I  added the attachment. See comment 1 there.
> https://bugzilla.mozilla.org/show_bug.cgi?id=1583416
>
> I only learned the existence of the URL 1 above AFTER I added the
> attachment
> since bugzilla said something about the failure of upload (?).
>
> I have not deleted the duplicate entries yet since the existence of the
> entry and the log on the bugzilla server may help whoever wants to debug
> the
> issue to find the cause of the strange bogus error message and what
> happened
> after I clicked a link the error message screen.
> (I DID, however, mark 1583416 as a dup of 1583415)
>
> At least, the error message screen, which I failed to capture,  ought to be
> rewritten IMHO to inform the poster what has happened correctly in an
> easy-to-comprehend manner.
>
> Thank you for your attention in advance.
>
> ___
> 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 remove: Fennec

[Dirkjan Ochtman]

On Mon, Sep 23, 2019 at 10:51 PM  wrote:

> As a happy Fennec end user with no direct involvement with Mozilla, I'm
> decidedly unhappy about the direction Mozilla seems to be going here.  I
> don't expect this complaint to have any effect on plans, but FYI.
>

Have you actually tried Fenix (Firefox Preview)? How did it fall short of
your usage of Fennec?

Kind regards,

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