Intent to ship: IntersectionObserver API
As of March 14 I intend to turn the IntersectionObserver API on by default on all platforms. It has been developed behind the dom.IntersectionObserver.enabled preference. Chrome is already shipping it since 51. Manual QA and fuzzing was successfully completed ( https://wiki.mozilla.org/QA/IntersectionObserver). A telemetry experiment run for 7 days, enabling the feature for 10% of our nightly (54 and 55) user population. No crashes or stability issues related to this feature occurred during that time. *Bug to turn on by default*: https://bugzilla.mozilla.org/show_bug.cgi?id= 1321865 *Link to standard*: https://wicg.github.io/IntersectionObserver/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Rationalising Linux audio backend support
Am Montag, 18. Juli 2016 15:57:27 UTC+2 schrieb Ralph Giles: > On Fri, Jul 15, 2016 at 3:34 AM, Kurt Roeckx wrote: > > > I also wonder how this fallback thing works. Things are linked to the > > pulseaudio library, but if the pulseaudio binary isn't installed things fall > > back to something else like alsa as far as I know. Is this something the > > pulseaudio library does, or do you need to write the fallback yourself? > > Currently, we try to dlopen the pulseaudio interface library and fall > back to alsa if that fails. So it's a build-time dependency (for the > headers) but not a run-time dependency. Except on gonk, where we > assume it's available and link to it directly. See > https://github.com/mozilla/gecko-dev/blob/378278ea830e7b01fb280d5274adccdfb2baab28/media/libcubeb/src/cubeb_pulse.c#L503 > > -r Contact the ALSA-devs: http://www.alsa-project.org/main/index.php/Main_Page Let Firefox work on ALSA-based systems without PA too, please! Thanx! ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Rationalising Linux audio backend support
Am Mittwoch, 15. März 2017 00:11:24 UTC+1 schrieb gfra...@gmail.com: > So this is were this idea started! > Great job guys, well, at least firefox is now unusable on Puppy Linux and low > profile OSS. yes, indeed: :( - A developer who don't like work much on ALSA and chose the easy way! (Hey, you are working for one of the famoust browsers in the world! You have no ressources for this???) - the decision to make a 5.1, DRM, AmazonPrime, commercial video on demand-multimediacenter compatible Multimediacenter as a browser - not recognizing how much Linux-Distros, projects and users prefer ALSA without Pulseaudio for several reasoons! - ignoring that ALSA is the soundbase in every Linux since more than 10y and PA is just a sound-server! - not informing the community to have this design-break early, so that they can decide and react and don't have distros/systems with broken sound with one ff-update in browser and a lot of work too! - basing on telemetry that is sayin`nothing!!! most users i know don't use telemetry in their browsers! Pure-ALSA-users are knowing as people who love FREEDOM much! ;-) And at the end some devs that explain that they are not uptodate with Linux-Sound-base!??? Hey c'mon: this is really how you decided this? i can't believe. Rollback to ALSA as the only main soundriver and soundsystem in Linux, maybe make Jack optional running too (it has a lot of potential) and maybe support pulseaudio too - but please let the people choose!!! I read in your group here that it was implemented before, that firefox DONT require PA as a hard dependency and that ff was using ALSA if PA was not found on system! THIS could be the best SOULution with your next build of FF! And a big note in www that you support ALSA again! It's no option to say that the people can recompile their alsa-based ff by theirself! I tried this one night with Linux Mint 17.3 and gcc 4.9 - but it was a mess! A lot of people are running away from ff now after years. It happens right now! maybe this are some hundreds or thousands - but hey: it does matter how you treat your users! So all i want is constractive and to motivate you: Please be patient! it's no fun for many people to have breaking sound with Linux Firefox, because of an update and without a note before. Respect this please. If you need more people working on ALSA with Firefox - get them on board! You are Mozilla! And hey: Where is the problem? firefox was building with ALSA for many years and it don't has to be so much work to implement 5.1 and fullduplex (use dmix or other options!) and keep it rolling. If you want to see Firefox 52 working on our little A/V-Distro - that is stable and just released in January and basing on Ubuntu 14.04, Linux Mint 17.3 and KXStudio - as a typical scene what happens on a typical ALSA-based Linux system that prefers to have FF as the default browser! http://mayastudio.tumblr.com/64bit http://qianastudio.tumblr.com That we now have to rebuild again with maybe another browser is just one example for what can happen, if you don't communicate breaks like this with the Linux Community. So i hope you will find a way and thinking about the fact, that there are many advanced Linux-users outside (without telemetry) that prefers ALSA without PA and that they love Firefox (too). Maybe the (sometimes harsh) feedback from your bugzilla will open your eyes!? ;-) https://bugzilla.mozilla.org/show_bug.cgi?id=1345661 It's emotional. This is a fact (too). but a problem to solve also... If you just keep on stopping supporting ALSA than it has to be so. There are alternative browsers. But i can't understand: BECAUSE Pulseaudio is setting upon ALSA and works NOT without ALSA! So ALSA is the (kernel-)sounddriver in every Linux-System and Pulseaudio just a server as a routing-backend! If the soundcard is not configured right and recognized by kernel and it's modules- than the soundcard DONT works with PA too! So you just have to arrange with ALSA and maybe it helps you, if you contact some devs there!??: Maybe they could help you same way like PA-devs do!?? I don't know - but it could be an option!# best regards, chalee, Phil and kAte http://alsa.opensrc.org/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Rationalising Linux audio backend support
So this is were this idea started! Great job guys, well, at least firefox is now unusable on Puppy Linux and low profile OSS. ___ 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
> On 12 Mar 2017, at 9:40 pm, Ehsan Akhgari wrote: > And I still don't understand what the proposal means with rebases in > practice. What if, after automation tries to land your change after you > got your final r+ the final rebase fails and you need to do a manual > rebase? Do you need to get another r+? What happens if you're touching > one of our giant popular headers and someone else manages to land a > conflict while your reviewer gets back to you? +1, this is a very common scenario for me… /me just loves when a new set of “rules” are put in place to prevent a problem that has never existed so far and will be a hindrance to everyone in the future. smime.p7s Description: S/MIME cryptographic signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: Use leave-open keyword to prevent bug closure when integration repositories are merged
On Thursday, February 20, 2014 at 1:41:12 AM UTC-8, Graeme McCutcheon wrote: > When mozilla-inbound was born, it becames custom to annotate the > whiteboard of bugs that were not to be resolved when the sheriffs merged > inbound to mozilla-central. Eventually mcMerge was written for the > sheriffs, which automated much of the post-merge Bugzilla updating. It > too watched for common annotations to prevent bug resolution. However, > sometimes it would get it wrong. Developers who infrequently need this > behaviour would likely have to stop what they were doing, and wander > over to IRC to find a sheriff in order to determine what the correct > incantation is. > > To that end, a 'leave-open' keyword has now been added to Bugzilla to > nail down the syntax of the annotation. mcMerge has been updated, so the > keyword is ready for use. (It continues to inspect the whiteboard, so > there is no need to update extant bugs). > > > Graeme > -- > http://www.graememcc.co.uk > https://twitter.com/graememcc ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: Use leave-open keyword to prevent bug closure when integration repositories are merged
On Thursday, February 20, 2014 at 1:41:12 AM UTC-8, Graeme McCutcheon wrote: > When mozilla-inbound was born, it becames custom to annotate the > whiteboard of bugs that were not to be resolved when the sheriffs merged > inbound to mozilla-central. Eventually mcMerge was written for the > sheriffs, which automated much of the post-merge Bugzilla updating. It > too watched for common annotations to prevent bug resolution. However, > sometimes it would get it wrong. Developers who infrequently need this > behaviour would likely have to stop what they were doing, and wander > over to IRC to find a sheriff in order to determine what the correct > incantation is. > > To that end, a 'leave-open' keyword has now been added to Bugzilla to > nail down the syntax of the annotation. mcMerge has been updated, so the > keyword is ready for use. (It continues to inspect the whiteboard, so > there is no need to update extant bugs). > > > Graeme > -- > http://www.graememcc.co.uk > https://twitter.com/graememcc ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Please write good commit messages before asking for code review
On Thursday, March 9, 2017 at 11:47:44 AM UTC-8, Ehsan Akhgari wrote: > I review a large number of patches on a typical day, and usually I have to > spend a fair amount of time to just understand what the patch is doing. As > the patch author, you can do a lot to help make this easier by *writing > better commit messages*. Starting now, I'm going to try out a new practice > for a while: I'm going to first review the commit message of all patches, > and if I can't understand what the patch does by reading the commit message > before reading any of the code, I'll r- and ask for another version of the > patch. > > I thank you in advance for your cooperation by writing great commit > messages. Happy hacking! > > Cheers, > -- > Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: Use leave-open keyword to prevent bug closure when integration repositories are merged
On Thursday, February 20, 2014 at 1:41:12 AM UTC-8, Graeme McCutcheon wrote: > When mozilla-inbound was born, it becames custom to annotate the > whiteboard of bugs that were not to be resolved when the sheriffs merged > inbound to mozilla-central. Eventually mcMerge was written for the > sheriffs, which automated much of the post-merge Bugzilla updating. It > too watched for common annotations to prevent bug resolution. However, > sometimes it would get it wrong. Developers who infrequently need this > behaviour would likely have to stop what they were doing, and wander > over to IRC to find a sheriff in order to determine what the correct > incantation is. > > To that end, a 'leave-open' keyword has now been added to Bugzilla to > nail down the syntax of the annotation. mcMerge has been updated, so the > keyword is ready for use. (It continues to inspect the whiteboard, so > there is no need to update extant bugs). > > > Graeme > -- > http://www.graememcc.co.uk > https://twitter.com/graememcc ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Is Alt+Shift+F10 a good shortcut key to open context menu forcibly on Windows and Linux?
Gecko supports that user can block web apps to prevent to open the context menu with Shift key. For instance, Shift+Right-Click and Shift+ContextMenu can open the context menu forcibly. Additionally, Shift+F10 is a well-known shortcut key to open context menu. However, this was not working as expected. The Shift state is referred unexpectedly and it always forcibly open the context menu. This bug was fixed by bug 1338369. On the other hand, users cannot open the context menu with Shift+F10 forcibly now and Shift state is necessary for this key combination. Therefore, for a11y, we need to declare other key combination as forcibly opening the context menu. Currently, Alt+Shift+F10 is the best candidate since DevTools use Ctrl+Shift+Foo a lot. Do you have some better idea or know a problem of using this key combination? I'd be happy if you'd let us know your idea. The bug is bug 1347079: https://bugzilla.mozilla.org/show_bug.cgi?id=1347079 Thanks in advance. -- Masayuki Nakano Software Engineer, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Quantum Flow Engineering Newsletter #1
Very interesting stuff. Of course, there are things scaping my understanding but it is good to know. Thank you for sharing, Eshang. El 9 mar. 2017 2:12 p. m., "Ehsan Akhgari" escribió: > Hi everyone, > > A while ago a number of engineers including myself started to look into a > performance project that turned into Quantum Flow. The focus of the > project is finding and prioritising the issues across the browser so we > will need help from many of you to get them fixed. I’m planning to write > regular updates about the project and highlight the focus areas and the > ongoing work. In this first email I’m going to start by giving some > background about how we started and where we are now. > > Quantum Flow is a performance task force focusing on eliminating > performance cliffs in the browser that aren’t part of other Quantum > projects. Project Quantum’s overall focus is to deliver a high > performance browser engine, and we are making some great progress on the > four main sub-projects that are attacking large portions of the rendering > pipeline, but that leaves us with various performance issues elsewhere in > the browser which users may still hit, and we have to fix all such issues > to ensure that the ultimate result is a next generation browser (and > browser engine) we all can be proud of. > > A good way to think about how Quantum Flow fits with the rest of Quantum > projects is to imagine it as the foundation we need for the other projects > to build up on. For example, if a bad bug somewhere in the browser causes > a jank in some code for a few hundreds of milliseconds, all of the benefit > that we obtain from cooperative scheduling of JS on the page with Quantum > DOM, resolving the styles in parallel on all of your CPU cores with Quantum > CSS and rasterize the page directly on the GPU with Quantum Render will > still result in a janky experience[0]. So we want to ensure that we remove > these types of roadblocks that would prevent the rest of Quantum to shine. > > The above description may feel a little big vague, and a little bit too > broad, so let me try to explain how the need for Quantum Flow became > apparent. Around the beginning of this year a number of us gathered for a > work week in Taipei with the goal of measuring and improving the > performance of Firefox on a few large websites that we knew we had > performance problems on. Initially we were only focusing on Google > Suite[1], and we started by profiling some of the test cases run by the > Hasal framework[2]. > > We had a bit of a difficult time finding actionable issues that we could > improve since these websites are massive and it can be extremely difficult > to find out why the overall time of some particular interaction is > different when comparing different browsers head to head. Also, we started > seeing some performance issues on those websites that were coming from > parts of the browser that were a bit surprising. For example, Chris Pearce > found out that on Google Docs, the content process can be blocked on the > parent process for a synchronous IPC message to initialize spell > checking[3] even though Google Docs doesn’t use the browser’s spell > checking facilities! > > Following the breadcrumbs, we started to wonder what else we can learn > about if we profile more usage scenarios in the browser. As you may > expect, we have found a fair amount of performance issues in various parts > of the browser. That’s hardly a surprise given the size and complexity of > the code base, but we have also learned a lot about the adverse impact of > some of these issues at play here. These findings have uncovered larger > problem areas that we decided we need to address as part of an initiative > that we call Quantum Flow. > > I’m planning to focus on one important class of performance issues in this > first email, mostly because it’s probably the most prevalent of the issues > we have been looking at so far: synchronous IPC messages from the content > process to the parent process. We currently have a high number[4] of these > types of messages. But of course not every one of these messages is equal, > we have gathered telemetry[5] on them. We have a tracker bug[6] to track > fixing them all. > > Some people here may remember the impact of synchronous I/O on the > performance of Firefox a few years ago, or you may have had to deal with > such performance issues in other applications. Based on my experience > measuring synchronous IPC, I now sometimes miss synchronous I/O. :-) I > have seen synchronous IPC calls that take amount to *seconds* of pause time > on the content process’s main thread. To some extent, with e10s, we hide > some of the pauses that happen on the content process. For example, APZ[7] > allows you to scroll even when the content process main thread is busy and > we can force-paint on tab switch when the content process is busy running > JS[8], but eventually some user out there is goin
Intent to remove UIEvent.isChar
UIEvent.isChar was (probably) designed for that web apps can distinguish the key combination inputs character(s). However, this is initialized only on macOS (always false on the other platforms) and other browsers don't support this. Unfortunately, Add-on SDK checked this value. Currently, you see garbage code of referring this here: https://dxr.mozilla.org/mozilla-central/rev/f9362554866b327700c7f9b18050d7b7eb3d2b23/addon-sdk/source/lib/sdk/keyboard/hotkeys.js#72 However, nobody refers this variable now. Some existing add-ons have old code of this. They refer the value but fortunately, the behavior after removing this attribute won't be changed because when it's false, they refer keyCode value but the value is always false even with current build except on macOS. So, I'd like to remove this non-standard attribute from Gecko. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1347073 -- Masayuki Nakano Software Engineer, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Objecting to some proposed editor changes
Le mardi 14 mars 2017 08:40:44 UTC+1, Brian Birtles a écrit :
> > 3. bug owner and module owner both don't seem to care about feedback
> > and comments
>
> I'm not sure if that's quite the case. The reviewer appears to be
> trying to clarify your concerns in a question posted to the bug before
> this mail. Perhaps he responded after your had already drafted the
> mail. In any case, I don't think they're ignoring your feedback and
> comments.
Right. Masayuki-san replied after I started this thread. But I could
not say he provided answers to my concerns in previous comments. In which
world can
editor.document.commandDispatcher.getControllerForCommand("cmd_increaseFont").doCommand("cmd_increaseFont")
be seen as better, more maintainable, more documentable, more usable than
editor.increaseFontSize()
? I don't know who will be the technical writer documenting this on MDN,
but I think that person will deserve gifts and love.
> > As the largest embedder of the editor (with BlueGriffon), such a class
> > of changes will have a large impact on BlueGriffon. If I entirely agree
> > with (and laud) the big cleanup done on the editor these days, the above
> > bug goes too far and I would like to state here my clear and firm
> > objection.
>
> Understood and much appreciated. Let's follow up on the bug.
Yes, thank you.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Objecting to some proposed editor changes
Hi Daniel, Thank you for your mail. On Tue, Mar 14, 2017 at 4:02 PM, glazou wrote: > 2. it forces to move to commands, while an API remains available > even if the corresponding command is disabled I'd like to understand this point. Perhaps we can follow up on the bug. > 3. bug owner and module owner both don't seem to care about feedback > and comments I'm not sure if that's quite the case. The reviewer appears to be trying to clarify your concerns in a question posted to the bug before this mail. Perhaps he responded after your had already drafted the mail. In any case, I don't think they're ignoring your feedback and comments. > As the largest embedder of the editor (with BlueGriffon), such a class > of changes will have a large impact on BlueGriffon. If I entirely agree > with (and laud) the big cleanup done on the editor these days, the above > bug goes too far and I would like to state here my clear and firm > objection. Understood and much appreciated. Let's follow up on the bug. Best regards, Brian ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Objecting to some proposed editor changes
Hello all, I would like to draw the attention about one bug that propose rather big changes to the editor: https://bugzilla.mozilla.org/show_bug.cgi?id=1336320 This bug does not seem to make sense to me: 1. it *drastically* complexifies Editor API calls, completely changing the embedding center of gravity for the Editor 2. it forces to move to commands, while an API remains available even if the corresponding command is disabled 3. bug owner and module owner both don't seem to care about feedback and comments As the largest embedder of the editor (with BlueGriffon), such a class of changes will have a large impact on BlueGriffon. If I entirely agree with (and laud) the big cleanup done on the editor these days, the above bug goes too far and I would like to state here my clear and firm objection. Thank you. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
