C++ method definition comments
Hi all,
Quick C++ style question.
A common pattern in Gecko is for method definitions to have a comment with the
'static' or 'virtual' qualification.
Before the reformat, the comment would be on it's own separate line [1]. Now
it's on the main line of the definition [2].
For example:
/* static */ void
Foo::Bar() {
...
}
vs.
/* static */ void Foo::Bar() {
...
}
Personally I think this now takes too much horizontal space from the main
definition, and would prefer it to be either on its own line or just removed.
Does anyone have an opinion on whether we still want these comments? And if so
whether it makes sense to move them back to their own line.
(My ulterior motive is that sublime text's indexer started failing to find
these definitions after the reformat, but that should be fixed regardless)
If you're interested in what removing these would entail, I wrote a regex to
make the change [3].
Thanks,
Ryan
[1]
https://hg.mozilla.org/mozilla-central/file/0348d472115d/layout/generic/nsFrame.cpp#l1759
[2]
https://hg.mozilla.org/mozilla-central/file/e4b9b1084292/layout/generic/nsFrame.cpp#l1756
[3] https://hg.mozilla.org/try/rev/31ab3e466b6f15dcdbb1aee47edabc7c358b86f2
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: New and improved "about:config" for Firefox Desktop
Showing only modified preferences looks like a common request, so my ask at the moment would be for actual examples of when you encounter this in a real scenario. If you're interested, check out bug 1502867 comment 3 and add a note the next time you find that the current page isn't enough for your use case. I'd expect most reports to come in after we've switched the default. Cheers, Paolo On 1/25/2019 10:52 PM, Mike Hommey wrote: On Fri, Jan 25, 2019 at 10:36:16PM +, Paolo Amadini wrote: On 1/25/2019 10:39 AM, Axel Hecht wrote: Is there a tracking bug for follow-ups? Please file bugs blocking bug 1493439, I'll triage them as necessary. filter [...] by modified This is bug 1502867, it is something we've considered but I'm a bit conflicted as it's only really used on 0.4% of page views and we have a better section dedicated to that use case in "about:support". Actually, I never realized we could order by column, and I've always thought what's in about:support is not enough, because it doesn't allow to edit. I don't think column ordering by modified is interesting in itself, but the fact that it allows to bring all modified prefs at the top is what's interesting, and a view similar to that of about:support, but editable, would go a long way. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Cookie policy/permission in live documents - proposal
On Fri, Jan 25, 2019 at 2:51 PM Daniel Veditz wrote: > > Your description equating cookies and storage within a document lifetime > makes sense. Is this intended to also apply to network requests? The > first-party document already has no access to 3rd party cookies so it > shouldn't matter at that level if Necko's rules change "live". If I'm on > twitter/facebook (which make constant background requests) and I clear my > entire cookie jar those documents are going to break. If I just tossed all > my cookies that's what I want! Discovering that I'm still logged into those > sites would be disturbing. Similarly, if I flip the "block 3rd-party > cookies" pref I'm going to react negatively if I still see tracker cookies > showing up just because I've left an active page open somewhere. > Cookies have been dynamic and racey since the dawn of time, both at the HTTP layer and in their reflection in DOM (document.cookie). Clearing your cookies isn't something that is changed by this proposal. I'm not too sure how Andrea was planning to handle cookie policy at the Necko layer but we have a lot of flexibility here and pages also can probably tolerate dynamic changes to document.cookie. I *think* handling the cookie policy globally at the Necko layer is probably easier but I'm curious to know Andrea's thoughts. -- Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Cookie policy/permission in live documents - proposal
On Thu, Jan 24, 2019 at 5:34 PM Martin Thomson wrote: > There are two reasons I can see why we might consider access to storage to > require "hiding" of some sort. > > The first is that we want to make sure that pages that were built with an > expectation of access to persistent storage, continue to work more or less > as they did before. We don't want them to be able to track people, but we > don't want them to suddenly catch fire. In that light, we're not really > hiding the fact that we are compartmentalizing persisted data, we're just > ensuring that those pages aren't surprised by errors. > > The second possibility is that we might want to be able to present a fake > environment to trackers that mimics a real one, but is limited. That is, > they might think that they are operating in an unconstrained iframe, but > they really aren't. > > I think that the fact that you can query with document.hasStorageAccess > puts us firmly in the first bucket. While we might present a somewhat > functional API, we're only doing that to avoid bustage for old documents, > and we're not trying to hide the fact that we're blocking their ability to > track. From that perspective, having this modelled as a permission (and > even allowing permission.query() to work) is probably OK. > Note that hasStorageAccess() doesn't reveal whether you have "storage" access, rather it reveals whether you have "storage access". The difference is very subtle, but here "storage access" means the thing that you gain if you'd called requestStorageAccess() before, or if the browser determines that you're eligible to receive the kind of access that function is capable of granting you. That is effectively a subversion of our soon-to-be-default cookie policy for third-party trackers for web compatibility, not "storage" access in the sense you're referring to here. But anyways, there is navigator.cookieEnabled which reveals the kind of storage access I think you're alluding to here, so the rest of your point is still valid. :-) > So this is really about the dynamism aspects of this. Clearly, building a > system where you can switch out the fake storage with the real one > dynamically is hard. The surface area is surprisingly big and the changes > are pervasive. That's infeasible. But I think that rather than saying > that permissions are a poor fit, I think that it would pay to think more > about how maybe we might fix this in permissions. Because I think that > this is something that works with permissions in many other respects - it's > something that we might want to bake into feature policy for instance. > > When we talked about permissions recently, we concluded that there were > some aspects of the .query() API that didn't properly reflect the range of > policies that might apply. For instance, permission for some actions is > conditional on an engagement gesture (a click or key press). Here I think > that we might have a new condition: the permission is conditional on the > page being refreshed. Now, I concede that perhaps this is too ambitious > and in the absence of other cases that share this constraint this might be > overgeneralizing, but I think that this fits reasonably well. > I think the reason why Andrea said permissions are a poor fit here is the dynamism aspect. For example, web pages aren't typically written with the expectation that localStorage/indexedDB methods will throw until a permission is granted out of band, or they start throwing when a permission is revoked. Our current behaviour which is exactly that will cause pages to break when the user does something to change permissions while there are live documents around. I don't think the problem is really about whether Permissions.query() is a good fit to query this type of permission. -- Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: New and improved "about:config" for Firefox Desktop
On Fri, Jan 25, 2019 at 10:36:16PM +, Paolo Amadini wrote: > On 1/25/2019 10:39 AM, Axel Hecht wrote: > > Is there a tracking bug for follow-ups? > > Please file bugs blocking bug 1493439, I'll triage them as necessary. > > > filter [...] by modified > > This is bug 1502867, it is something we've considered but I'm a bit > conflicted as it's only really used on 0.4% of page views and we have a > better section dedicated to that use case in "about:support". Actually, I never realized we could order by column, and I've always thought what's in about:support is not enough, because it doesn't allow to edit. I don't think column ordering by modified is interesting in itself, but the fact that it allows to bring all modified prefs at the top is what's interesting, and a view similar to that of about:support, but editable, would go a long way. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: New and improved "about:config" for Firefox Desktop
On 1/25/2019 10:39 AM, Axel Hecht wrote: Is there a tracking bug for follow-ups? Please file bugs blocking bug 1493439, I'll triage them as necessary. filter [...] by modified This is bug 1502867, it is something we've considered but I'm a bit conflicted as it's only really used on 0.4% of page views and we have a better section dedicated to that use case in "about:support". While not conceptually difficult to write, if we add one more input field and make the filter based on a variable state rather than just the invariant name, then the complexity goes up a notch and there's a higher number of edge cases and combinations to write regression tests for. Maybe give this version combined with "about:support" a try for a while? Cheers, Paolo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Cookie policy/permission in live documents - proposal
Your description equating cookies and storage within a document lifetime makes sense. Is this intended to also apply to network requests? The first-party document already has no access to 3rd party cookies so it shouldn't matter at that level if Necko's rules change "live". If I'm on twitter/facebook (which make constant background requests) and I clear my entire cookie jar those documents are going to break. If I just tossed all my cookies that's what I want! Discovering that I'm still logged into those sites would be disturbing. Similarly, if I flip the "block 3rd-party cookies" pref I'm going to react negatively if I still see tracker cookies showing up just because I've left an active page open somewhere. -Dan Veditz ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charter: SVG Working Group
Thanks. Revised comments submitted at:
https://lists.w3.org/Archives/Public/public-new-work/2019Jan/0010.html
-David
On Thursday 2019-01-24 23:32 -0800, Tantek Çelik wrote:
> Comments inline.
>
> On Thu, Jan 24, 2019 at 5:54 PM L. David Baron wrote:
> >
> > On Sunday 2018-12-23 09:59 -0800, L. David Baron wrote:
> > > The W3C is proposing a revised charter for:
> > >
> > > Scalable Vector Graphics (SVG) Working Group
> > > https://www.w3.org/Graphics/SVG/svg-2019-ac.html
> > > https://lists.w3.org/Archives/Public/public-new-work/2018Dec/0006.html
> > >
> > > Mozilla has the opportunity to send comments or objections through
> > > Friday, January 25.
> > >
> > > Please reply to this thread if you think there's something we should
> > > say as part of this charter review, or if you think we should
> > > support or oppose it. Given our past involvement, we should
> > > probably have some comment, even if it's simply in support.
> > >
> > > A comparison with the current charter is:
> > > https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2F2017%2F04%2Fsvg-2017.html=https%3A%2F%2Fwww.w3.org%2FGraphics%2FSVG%2Fsvg-2019-ac.html
> >
> > Based on the comments from Henri and Cameron, I propose to submit
> > the following comments. Please let me know in the next 24 hours if
> > there's anything wrong with them.
>
> In general this is very good.
>
>
> > -David
> >
> > We generally support this charter and its focus on stabilization and
> > testing, although we're not sure we'll be able to put significant effort
> > into supporting the group's work.
>
> Add: ... especially any new features.
>
> Based on just the past two years of new feature implementation (CSS
> etc.), It's quite likely that we wouldn't be able to prioritize
> allocating time to debating/discussing details of new SVG features
> (much less implementing them), before the end of this charter period.
>
> > There are two particular concerns we have with the charter.
> >
> > The first is with the sentence "As a secondary focus, the group may address
> > modules for new graphical features for SVG, once there is broad consensus
> > on adding each such feature to the Web Platform." We'd like this sentence
> > to be clearer that "broad consensus" needs to include consensus of
> > implementors; it shouldn't be sufficient if there are a significant number
> > of users interested in a feature but only a single implementor.
>
> Two things:
>
> 1. This charter sentence concerns me a lot. It feels too open ended
> and underspecified as to what new graphical features. I'd prefer that
> this sentence be rewritten for new feature incubation / development to
> happen across the SVG CG / SVG WG similar to new feature incubation /
> development happens in WICG and graduates to WPWG (Soon to be
> WebAppsWG).
>
> 2. This (even the just the existing concerns noted above) is worth a
> FO. I would reword the double-negative ("shouldn't be sufficient ...
> but only") for clarity, e.g.:
> "We'd like this sentence to be clearer that "broad consensus" needs to
> include consensus of implementors; a single implementor is
> insufficient; broad consensus must be include explicit interest from
> at least two implementors in addition to users interested in a
> feature."
>
>
> > The second is with the statement that SVG 2 updates SVG 1.1 to include
> > HTML5-compatible parsing. While that's probably fine, we'd like it to be
> > clear that changes to the HTML parsing algorithm are out of scope; the HTML
> > parsing algorithm should be maintained in the HTML specification, and
> > should be changed very rarely due to the high costs of updating both
> > client-side and server-side software and the costs of those pieces of
> > software being out-of-sync.
> >
> >
> > We also have a few other smaller comments:
> >
> > - The proposed "Core SVG" specification seems in some ways to duplicate or
> > replace the work in https://www.w3.org/TR/svg-integration/ . It would be
> > useful to clarify the relationship.
> >
> > - The statement in the Scope section that "The SVG WG develops a single
> > deliverable" seems to conflict with the deliverables section.
>
> These are good. Also perhaps drop this from 3.1 W3C Groups:
> "
> Web Platform Working Group
> Coordinate on integration of SVG and HTML, and on compatibility with
> the Canvas API specifications.
> "
> As that WG will not exist by the time the SVG WG gets restarted.
>
> Thanks,
>
> Tantek
--
턞 L. David Baron http://dbaron.org/ 턂
턢 Mozilla https://www.mozilla.org/ 턂
Before I built a wall I'd ask to know
What I was walling in or walling out,
And to whom I was like to give offense.
- Robert Frost, Mending Wall (1914)
signature.asc
Description: PGP signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
Re: New and improved "about:config" for Firefox Desktop
On Thu, Jan 24, 2019, at 2:35 PM, Paolo Amadini wrote: > Last year a group of students, Luke, Matthias, and Vincent, designed and > implemented a new version of "about:config" in order to improve the > ergonomics and align the look and feel with other in-content Firefox > pages. They did an amazing job, working with design input from Amy Lee > and with myself doing code reviews. > > I'm happy to announce that this work will be available to everyone in > Firefox 67, and can be already used in Nightly at this URL: > > chrome://browser/content/aboutconfig/aboutconfig.html I only took a quick look at this locally but it looks great, nice work! I know about:config isn't very visible but I still wind up using it fairly often and it's nice to see it get a well-thought-out rewrite. (Ditching XUL for HTML is just the icing on the cake!) Looking forward to having this become the default about:config! -Ted ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re[2]: New and improved "about:config" for Firefox Desktop
I'm interested in the tracking bug for followup requests as well, and where to file feature requests. I'd love to see a "date changed" column on that page, for example. Future-wish bikeshedding aside, this is good work, thanks to you and your team. - mhoye -- Original Message -- From: "Frederik Braun" To: "Tom Schuster" Cc: "Axel Hecht" ; "dev-platform" Sent: 2019-01-25 8:55:46 AM Subject: Re: New and improved "about:config" for Firefox Desktop Agreed. If there's one special feature besides search I've been using most, it was sorting by modified Am Fr., 25. Jan. 2019, 12:16 hat Tom Schuster geschrieben: I am always happy to see more xul going away. Please implement a filter to only show modified preferences. Sorting by modified is probably my most common operation after search on the old page. Thanks On Fri, Jan 25, 2019 at 11:40 AM Axel Hecht wrote: > > Is there a tracking bug for follow-ups? > > I'd have a few, adding pref w/out search (*), show add on screen for > long searches, filter/order by modified, search in values, can't abort edit. > > (*) I just realize that I didn't understand how "add" works. Maybe the > bug is to make that discoverable? > > Axel > > Am 24.01.19 um 20:31 schrieb Paolo Amadini: > > Last year a group of students, Luke, Matthias, and Vincent, designed and > > implemented a new version of "about:config" in order to improve the > > ergonomics and align the look and feel with other in-content Firefox > > pages. They did an amazing job, working with design input from Amy Lee > > and with myself doing code reviews. > > > > I'm happy to announce that this work will be available to everyone in > > Firefox 67, and can be already used in Nightly at this URL: > > > > chrome://browser/content/aboutconfig/aboutconfig.html > > > > Most improvements are the natural result of using HTML instead of XUL: > > > > * There are visible buttons for editing preferences > > * String values are displayed in full as multiline text > > * Find in page works for both names and values > > * Triple click selects one preference name or value quickly > > * Text selection works on multiple preferences > > * The context menu is the same as regular web pages > > - Copy to the clipboard > > - Open selected link > > - Search with your preferred engine > > * Search results don't include spurious value matches anymore > > * Closing and reopening the browser while the tab is pinned > > preserves the search term > > > > We've not just converted the old page, we've designed something new > > based on actual use cases, telemetry data, and opportunity cost. We > > preferred natural HTML page interactions, for example a double click now > > selects text instead of toggling the value. The way the page is explored > > with screen readers has also changed, and we've ensured that the new way > > is still clear and easy to use. > > > > We're still keeping the old "about:config" around at the following URL > > for a while, to mitigate risk related to unforeseen circumstances: > > > > chrome://global/content/config.xul > > > > Thunderbird will not be affected by this change initially, but at some > > point we'll remove the old code from mozilla-central since Thunderbird > > will be the only remaining user. > > > > > > *Performance* > > > > This page can be slower than the old one in some cases. On slower > > machines the page may take a moment to display all preferences, if you > > so choose. We worked around this by waiting for the first input before > > displaying results, as 93% of "about:config" page shows include a search > > anyway. Navigation, scrolling, and find in page are then fast. > > > > We've used performance profiling to optimize the page and avoid the > > slowest layout modes, but we've not compromised on using the latest > > best practices for Firefox Desktop like Fluent localization, which are > > anyways in the process of being optimized on their own. > > > > We've explicitly chosen to avoid virtualizing the list, that is only > > rendering visible DOM nodes, because this would add complexity that is > > not needed for an internal page. It would also nullify most of the > > advantages in accessibility and usability that we gained at a low cost > > just because we're using a simple HTML table. Effort would be better > > spent on optimizing the web for the layout of tables of about 3,000 > > rows, which would benefit every web site instead of Firefox only. > > > > > > *Tutorials and screenshots on the web* > > > > While with some features there is a concern that a change would make it > > more difficult for users to follow instructions found in older tutorials > > on the web, this is much less of a concern in this case, given that the > > page caters to experienced users and the changes affect presentation > > rather than actual functionality. > > > > In fact, existing information on the
Re: New and improved "about:config" for Firefox Desktop
Agreed. If there's one special feature besides search I've been using most, it was sorting by modified Am Fr., 25. Jan. 2019, 12:16 hat Tom Schuster geschrieben: > I am always happy to see more xul going away. > > Please implement a filter to only show modified preferences. Sorting > by modified is probably my most common operation after search on the > old page. > > Thanks > > On Fri, Jan 25, 2019 at 11:40 AM Axel Hecht wrote: > > > > Is there a tracking bug for follow-ups? > > > > I'd have a few, adding pref w/out search (*), show add on screen for > > long searches, filter/order by modified, search in values, can't abort > edit. > > > > (*) I just realize that I didn't understand how "add" works. Maybe the > > bug is to make that discoverable? > > > > Axel > > > > Am 24.01.19 um 20:31 schrieb Paolo Amadini: > > > Last year a group of students, Luke, Matthias, and Vincent, designed > and > > > implemented a new version of "about:config" in order to improve the > > > ergonomics and align the look and feel with other in-content Firefox > > > pages. They did an amazing job, working with design input from Amy Lee > > > and with myself doing code reviews. > > > > > > I'm happy to announce that this work will be available to everyone in > > > Firefox 67, and can be already used in Nightly at this URL: > > > > > > chrome://browser/content/aboutconfig/aboutconfig.html > > > > > > Most improvements are the natural result of using HTML instead of XUL: > > > > > > * There are visible buttons for editing preferences > > > * String values are displayed in full as multiline text > > > * Find in page works for both names and values > > > * Triple click selects one preference name or value quickly > > > * Text selection works on multiple preferences > > > * The context menu is the same as regular web pages > > > - Copy to the clipboard > > > - Open selected link > > > - Search with your preferred engine > > > * Search results don't include spurious value matches anymore > > > * Closing and reopening the browser while the tab is pinned > > > preserves the search term > > > > > > We've not just converted the old page, we've designed something new > > > based on actual use cases, telemetry data, and opportunity cost. We > > > preferred natural HTML page interactions, for example a double click > now > > > selects text instead of toggling the value. The way the page is > explored > > > with screen readers has also changed, and we've ensured that the new > way > > > is still clear and easy to use. > > > > > > We're still keeping the old "about:config" around at the following URL > > > for a while, to mitigate risk related to unforeseen circumstances: > > > > > > chrome://global/content/config.xul > > > > > > Thunderbird will not be affected by this change initially, but at some > > > point we'll remove the old code from mozilla-central since Thunderbird > > > will be the only remaining user. > > > > > > > > > *Performance* > > > > > > This page can be slower than the old one in some cases. On slower > > > machines the page may take a moment to display all preferences, if you > > > so choose. We worked around this by waiting for the first input before > > > displaying results, as 93% of "about:config" page shows include a > search > > > anyway. Navigation, scrolling, and find in page are then fast. > > > > > > We've used performance profiling to optimize the page and avoid the > > > slowest layout modes, but we've not compromised on using the latest > > > best practices for Firefox Desktop like Fluent localization, which are > > > anyways in the process of being optimized on their own. > > > > > > We've explicitly chosen to avoid virtualizing the list, that is only > > > rendering visible DOM nodes, because this would add complexity that is > > > not needed for an internal page. It would also nullify most of the > > > advantages in accessibility and usability that we gained at a low cost > > > just because we're using a simple HTML table. Effort would be better > > > spent on optimizing the web for the layout of tables of about 3,000 > > > rows, which would benefit every web site instead of Firefox only. > > > > > > > > > *Tutorials and screenshots on the web* > > > > > > While with some features there is a concern that a change would make it > > > more difficult for users to follow instructions found in older > tutorials > > > on the web, this is much less of a concern in this case, given that the > > > page caters to experienced users and the changes affect presentation > > > rather than actual functionality. > > > > > > In fact, existing information on the web can more easily become > obsolete > > > because the preferences go away or change their meaning, rather than > > > because of a change in how the values can be changed. > > > > > > > > > *Features that have not been rewritten* > > > > > > If the new page is missing a feature that the old one used to have, > > >
Re: New and improved "about:config" for Firefox Desktop
I am always happy to see more xul going away. Please implement a filter to only show modified preferences. Sorting by modified is probably my most common operation after search on the old page. Thanks On Fri, Jan 25, 2019 at 11:40 AM Axel Hecht wrote: > > Is there a tracking bug for follow-ups? > > I'd have a few, adding pref w/out search (*), show add on screen for > long searches, filter/order by modified, search in values, can't abort edit. > > (*) I just realize that I didn't understand how "add" works. Maybe the > bug is to make that discoverable? > > Axel > > Am 24.01.19 um 20:31 schrieb Paolo Amadini: > > Last year a group of students, Luke, Matthias, and Vincent, designed and > > implemented a new version of "about:config" in order to improve the > > ergonomics and align the look and feel with other in-content Firefox > > pages. They did an amazing job, working with design input from Amy Lee > > and with myself doing code reviews. > > > > I'm happy to announce that this work will be available to everyone in > > Firefox 67, and can be already used in Nightly at this URL: > > > > chrome://browser/content/aboutconfig/aboutconfig.html > > > > Most improvements are the natural result of using HTML instead of XUL: > > > > * There are visible buttons for editing preferences > > * String values are displayed in full as multiline text > > * Find in page works for both names and values > > * Triple click selects one preference name or value quickly > > * Text selection works on multiple preferences > > * The context menu is the same as regular web pages > > - Copy to the clipboard > > - Open selected link > > - Search with your preferred engine > > * Search results don't include spurious value matches anymore > > * Closing and reopening the browser while the tab is pinned > > preserves the search term > > > > We've not just converted the old page, we've designed something new > > based on actual use cases, telemetry data, and opportunity cost. We > > preferred natural HTML page interactions, for example a double click now > > selects text instead of toggling the value. The way the page is explored > > with screen readers has also changed, and we've ensured that the new way > > is still clear and easy to use. > > > > We're still keeping the old "about:config" around at the following URL > > for a while, to mitigate risk related to unforeseen circumstances: > > > > chrome://global/content/config.xul > > > > Thunderbird will not be affected by this change initially, but at some > > point we'll remove the old code from mozilla-central since Thunderbird > > will be the only remaining user. > > > > > > *Performance* > > > > This page can be slower than the old one in some cases. On slower > > machines the page may take a moment to display all preferences, if you > > so choose. We worked around this by waiting for the first input before > > displaying results, as 93% of "about:config" page shows include a search > > anyway. Navigation, scrolling, and find in page are then fast. > > > > We've used performance profiling to optimize the page and avoid the > > slowest layout modes, but we've not compromised on using the latest > > best practices for Firefox Desktop like Fluent localization, which are > > anyways in the process of being optimized on their own. > > > > We've explicitly chosen to avoid virtualizing the list, that is only > > rendering visible DOM nodes, because this would add complexity that is > > not needed for an internal page. It would also nullify most of the > > advantages in accessibility and usability that we gained at a low cost > > just because we're using a simple HTML table. Effort would be better > > spent on optimizing the web for the layout of tables of about 3,000 > > rows, which would benefit every web site instead of Firefox only. > > > > > > *Tutorials and screenshots on the web* > > > > While with some features there is a concern that a change would make it > > more difficult for users to follow instructions found in older tutorials > > on the web, this is much less of a concern in this case, given that the > > page caters to experienced users and the changes affect presentation > > rather than actual functionality. > > > > In fact, existing information on the web can more easily become obsolete > > because the preferences go away or change their meaning, rather than > > because of a change in how the values can be changed. > > > > > > *Features that have not been rewritten* > > > > If the new page is missing a feature that the old one used to have, > > there is probably a good reason. Luke added telemetry probes to the > > current "about:config" so we know how people use it. It's basically just > > one mode of operation across all channels: search, then maybe edit or > > add a preference. > > > > There are more details in the history section below, but this is to say > > that it is unlikely that we would accept a patch to add back a
Re: New and improved "about:config" for Firefox Desktop
Is there a tracking bug for follow-ups? I'd have a few, adding pref w/out search (*), show add on screen for long searches, filter/order by modified, search in values, can't abort edit. (*) I just realize that I didn't understand how "add" works. Maybe the bug is to make that discoverable? Axel Am 24.01.19 um 20:31 schrieb Paolo Amadini: Last year a group of students, Luke, Matthias, and Vincent, designed and implemented a new version of "about:config" in order to improve the ergonomics and align the look and feel with other in-content Firefox pages. They did an amazing job, working with design input from Amy Lee and with myself doing code reviews. I'm happy to announce that this work will be available to everyone in Firefox 67, and can be already used in Nightly at this URL: chrome://browser/content/aboutconfig/aboutconfig.html Most improvements are the natural result of using HTML instead of XUL: * There are visible buttons for editing preferences * String values are displayed in full as multiline text * Find in page works for both names and values * Triple click selects one preference name or value quickly * Text selection works on multiple preferences * The context menu is the same as regular web pages - Copy to the clipboard - Open selected link - Search with your preferred engine * Search results don't include spurious value matches anymore * Closing and reopening the browser while the tab is pinned preserves the search term We've not just converted the old page, we've designed something new based on actual use cases, telemetry data, and opportunity cost. We preferred natural HTML page interactions, for example a double click now selects text instead of toggling the value. The way the page is explored with screen readers has also changed, and we've ensured that the new way is still clear and easy to use. We're still keeping the old "about:config" around at the following URL for a while, to mitigate risk related to unforeseen circumstances: chrome://global/content/config.xul Thunderbird will not be affected by this change initially, but at some point we'll remove the old code from mozilla-central since Thunderbird will be the only remaining user. *Performance* This page can be slower than the old one in some cases. On slower machines the page may take a moment to display all preferences, if you so choose. We worked around this by waiting for the first input before displaying results, as 93% of "about:config" page shows include a search anyway. Navigation, scrolling, and find in page are then fast. We've used performance profiling to optimize the page and avoid the slowest layout modes, but we've not compromised on using the latest best practices for Firefox Desktop like Fluent localization, which are anyways in the process of being optimized on their own. We've explicitly chosen to avoid virtualizing the list, that is only rendering visible DOM nodes, because this would add complexity that is not needed for an internal page. It would also nullify most of the advantages in accessibility and usability that we gained at a low cost just because we're using a simple HTML table. Effort would be better spent on optimizing the web for the layout of tables of about 3,000 rows, which would benefit every web site instead of Firefox only. *Tutorials and screenshots on the web* While with some features there is a concern that a change would make it more difficult for users to follow instructions found in older tutorials on the web, this is much less of a concern in this case, given that the page caters to experienced users and the changes affect presentation rather than actual functionality. In fact, existing information on the web can more easily become obsolete because the preferences go away or change their meaning, rather than because of a change in how the values can be changed. *Features that have not been rewritten* If the new page is missing a feature that the old one used to have, there is probably a good reason. Luke added telemetry probes to the current "about:config" so we know how people use it. It's basically just one mode of operation across all channels: search, then maybe edit or add a preference. There are more details in the history section below, but this is to say that it is unlikely that we would accept a patch to add back a certain feature just because it used to be present before. All patches would have to be motivated by an actual need and include exhaustive regression tests. That said, we have ideas for supporting new use cases for browser developers, like pinning a list of favorites or just showing recently modified preferences first, but we don't plan to start working on them before the current version reaches Release. *More details on history, motivation, and process* If you're reading this you probably already have a good idea of what we're talking about, but it's worth stating how we thought about the
Re: Intent to ship: implicit rel=noopener for target=_blank on anchor and area elements
On Fri, Jan 25, 2019 at 1:52 AM Tantek Çelik wrote: > I am seeing some publisher uptake of rel="noopener" so it is good that > we are shipping this. To be clear, we've supported rel="noopener" for a while. This makes it so that you don't need to specify rel="noopener" if your target attribute is set to "_blank". ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
