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:
/*
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
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
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,
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
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
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
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,
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
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 --
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
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
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?
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
14 matches
Mail list logo
