Hi Dale,
It seems that this feature is not being developed with the hope of it
turning into a cross-browser autodiscovery of search extensions in the
future. With that in mind, I'd like to ask if it is really necessary to
expose a new meta tag to the web platform, given the unclear path to the
Hi everyone,
We currently allow cross-origin iframes to request notification
permissions. This is problematic because we'd like to move to a model
where permissions are only requested for the top-level document’s origin in
order to show non-address-bar origins as little to the user as possible.
On Tue, Jul 23, 2019 at 2:50 PM Bryce Seager van Dyk
wrote:
> On Sunday, July 21, 2019 at 10:18:02 PM UTC-7, Karl Tomlinson wrote:
> > Near the top of
> >
> https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style
> > there is
> > > New code should try to conform to these
On Mon, Jul 22, 2019 at 1:20 AM Karl Tomlinson wrote:
> Near the top of
>
> https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style
> there is
> > New code should try to conform to these standards, so it is as
> > easy to maintain as existing code. [...]
> >
> > This
Thanks Kershaw for fixing this. I was curious why you expect this to ship
in Firefox 71 but not 70?
On Tue, Jul 16, 2019 at 1:56 PM Kershaw Jang wrote:
> Hi everyone,
>
> *Summary*:
> Allow more wildcards in CORS headers when used without credential.
> So, the new syntax for these http
On Mon, Jul 8, 2019 at 11:00 PM Gerald Squelart
wrote:
> Thank you all for some very interesting discussions so far.
>
> Even if we don't take blanket steps to avoid unsigned types in
> non-bitfield/modulo cases (as suggested by our newly-adopted Google style),
> at least hopefully we're now
ows with the right NVIDIA GPU driver).
>
> Currently, DevTools only checks if the backdrop-filter pref is enabled and
> doesn't check if WebRender is enabled. If we decide on approach 2, we would
> need to check for the cases that you mentioned.
>
> Thanks,
> Connor
On Sat, Jul 6, 2019 at 1:56 AM Anne van Kesteren wrote:
> On Sat, Jul 6, 2019 at 2:44 AM Ehsan Akhgari
> wrote:
> > Does the page need to include some of this description?
>
> It has this:
>
> # It's acceptable to merge the "intent to prototype" into the
On Wed, Jul 3, 2019 at 5:48 AM Anne van Kesteren wrote:
> Hi all,
>
> In consultation with others I have made some adjustments to
> https://wiki.mozilla.org/ExposureGuidelines.
>
> “Intent to implement” has been renamed to “Intent to prototype” to signify
> more clearly that the change does not
Hi everyone,
*Summary*: I'm planning to move the clear/captureEvents/releaseEvents no-op
methods as well as the all property from HTMLDocument to Document to bring
our implementation of these methods and property on par with the HTML spec.
*Bug*:
On Wed, Jul 3, 2019 at 8:45 PM Bryce Seager van Dyk
wrote:
> On Wednesday, July 3, 2019 at 2:27:30 PM UTC-7, Chris Peterson wrote:
> > On 7/3/2019 11:37 AM, Bryce Seager van Dyk wrote:
> > > I wanted to clarify, and discuss if needed, our styling of #define
> guards. My understanding is that we
On Thu, Jul 4, 2019 at 8:05 AM Gerald Squelart
wrote:
> > > - Our latest coding style [1] points at Google's, which has a section
> about Integer Types [3], and the basic gist is: Use plain `int` for
> "not-too-big" numbers
> >
> > If you can 100% guarantee that they will not be too big, right?
On Fri, Jul 5, 2019 at 2:48 AM Jeff Gilbert wrote:
> Yes I intend to write precisely that, if we ban unsigned types.
> However I'm not really convinced that throwing out unsigned types is
> the right move.
>
Note that such a class, if it performs assertions, is actually completely
different
On Mon, Jul 1, 2019 at 8:54 PM Connor Brewster
wrote:
> Platform coverage: All platforms using the Gecko rendering engine
> (WebRender enabled only)
>
> Target release: Firefox 71 (WebRender enabled only)
>
> DevTools bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1561060
>
Hi Connor,
Since
Hi everyone,
*Summary*: I'm planning to move the fgColor, linkColor, alinkColor,
vlinkColor and bgColor properties from HTMLDocument to Document to bring
our implementation of these properties on par with the HTML spec.
*Bug*:
*Link to standard*:
Hi everyone,
*Summary*: I'm planning to move the designMode getter/setter as well as
execCommand(), and the queryCommand*() methods from HTMLDocument to Document
to bring our implementation of these APIs on par with the HTML spec.
*Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=1415270
*Link
Hi everyone,
*Summary*: I'm planning to move the open(), close(), write() and writeln()
methods from HTMLDocument to Document to bring our implementation of this
attribute on par with the HTML spec.
*Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=1549560
*Link to standard*:
Hi everyone,
*Summary*: I'm planning to move the domain attribute from HTMLDocument to
Document to bring our implementation of this attribute on par with the HTML
spec.
*Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=1467625
*Link to standard*:
You're right about both issues. We reused the firstPartyDomain field in
OriginAttributes mostly for simplicity but long term if this feature proves
to be viable we should probably introduce a new OA field specifically to be
used for it to avoid these types of problems. That being said, making it
*Summary*: This feature adds a token to the window.open() feature argument
to allow callers to specify that the window should be opened without a
referrer (and an opener).
*Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=1527287
*Link to standard*: https://github.com/whatwg/html/pull/4331
Hi everyone,
*Summary*: I'm planning to move the cookie attribute from HTMLDocument to
Document to bring our implementation of this attribute on par with the HTML
spec.
*Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=144795
*Link to standard*:
Hi everyone,
As of Firefox 68 I'm planning to turn off support for non-standard
XMLDocument.load and XMLDocument.async APIs. These are really old APIs
that allow developers to load an XML document over the network
synchronously or asynchronously but were never standardized and implemented
by
On Wed, Apr 3, 2019 at 7:15 PM wrote:
> Hi, is there an expected date for the cookie change to go to production?
>
No, this is only an experiment turned on for Firefox Nightly at this
point. You can watch this mailing list for future updates as we make
future plans about it going forward.
>
On Tue, Apr 2, 2019 at 6:25 AM wrote:
> Hi,
>
> I know Google Analytics very well, only the _ga cookie is used to
> recognize a web browser across visits.
>
Great, thanks for confirming this. So based on the data you cited before
it looks like this change hasn't made any significant impact on
On Fri, Mar 22, 2019 at 1:55 PM wrote:
> Hi Ehsan,
>
> Thanks for the follow up.
> I don't have access to a macOS computer with that 12.0.3 version of Safari
>
> On the other hand I have access to Google Analytics data for multiple
> sites, not the top 100 Alexa, but I don't see any evidence of
Hi Rik,
Sorry for the late reply.
On Fri, Mar 22, 2019 at 10:10 PM Rik Cabanier wrote:
>
>
> On Fri, Mar 22, 2019 at 6:07 AM Ehsan Akhgari
> wrote:
>
>> On Thu, Mar 21, 2019, 9:39 PM Rik Cabanier, wrote:
>>
>>> Why are these sites not included in the &quo
On Tue, Mar 19, 2019, 6:15 PM , wrote:
> Hi
>
> Sorry but I don't read the webkit.org blog post in the same way
> https://webkit.org/blog/8613/intelligent-tracking-prevention-2-1/
>
> "The **beta** releases of iOS 12.2 and Safari 12.1 on macOS High Sierra
> and Mojave include an updated version
On Fri, Mar 15, 2019 at 11:35 AM Tom Ritter wrote:
> Thanks for more details on the use case.
>
> On Wed, Mar 6, 2019 at 1:35 AM wrote:
> >
> > On Monday, February 25, 2019 at 4:17:29 PM UTC-8, Martin Thomson wrote:
> > > To add to Dan's comments here...
> > >
> > > Assuming that I'm reading
On Thu, Mar 7, 2019 at 7:31 PM Ehsan Akhgari
wrote:
> *Estimated or target release*: in which version do you want to/plan to
> release this? Getting enabled in Nightly in 67, staying Nightly only for
> now in order to collect some early feedback. No estimated target release
> a
On Fri, Mar 8, 2019 at 11:54 AM James Graham wrote:
> On 08/03/2019 15:06, Boris Zbarsky wrote:
> > On 3/7/19 7:31 PM, Ehsan Akhgari wrote:
> >> *web-platform-tests*: This is an intervention which different engines do
> >> not agree on yet. Creating a web-platfor
*Summary*: With Enhanced Tracking Protection gradually rolling out to our
users on the release channel, we are limiting the ability of third-party
trackers to store unique client identifiers on the user's device in order
to capture a history of their browsing across different sites. However we
*Summary*: As part of the anti-tracking project, we'd like to experiment
with a new feature in order to mitigate the impact of third-party tracking
scripts running in top-level documents. As we are planning to start
removing the storage capabilities of third-party trackers, which removes
their
ary 28, 2019 at 11:08:32 AM UTC-5, Ehsan Akhgari wrote:
> > > On Mon, Jan 28, 2019 at 10:51 AM Daniel Veditz
> > wrote:
> > >
> > > > On Mon, Jan 28, 2019 at 12:57 AM Andrea Marchesini <
> > > > amarches...@mozilla.com> wrote:
> > >
On Wed, Jan 30, 2019 at 1:35 AM Karl Tomlinson wrote:
> Ehsan Akhgari writes:
>
> > On Mon, Jan 28, 2019 at 2:58 PM Jeff Gilbert
> wrote:
> >
> >> I would much rather revert to:
> >> /*static*/ void
> >> Foo::Bar()
> >>
> >> The
On Wed, Jan 30, 2019 at 1:30 AM Karl Tomlinson wrote:
> Ehsan Akhgari writes:
>
> > On Mon, Jan 28, 2019 at 6:27 PM Ryan Hunt wrote:
> >
> >> [...]
> >>
> >> So for converting from C-style to C++-style, that would be:
> >>
> >> /* s
On Tue, Jan 29, 2019 at 6:40 PM wrote:
> On Wednesday, January 30, 2019 at 9:57:02 AM UTC+11, Ehsan Akhgari wrote:
> > On Mon, Jan 28, 2019 at 7:10 PM wrote:
> >
> > > Just a thought: Would it be worth considering a blank macro, e.g.:
> > > static void foo(
]
> https://hg.mozilla.org/mozilla-central/file/e4b9b1084292/layout/generic/nsFrame.cpp#l1023
> >
> > Thanks,
> > Ryan
> >
> > ‐‐‐ Original Message ‐‐‐
> > On Monday, January 28, 2019 12:51 PM, Ehsan Akhgari
> wrote:
> >
> &
e such
> deviations from Google Style, since it's all handled for us.
>
> On Mon, Jan 28, 2019 at 10:52 AM Ehsan Akhgari
> wrote:
>
>
> > This is indeed one of the cases where the reformat has made things worse.
> > I think as a couple of people have already said, we'
consistently do that.
>
> [1]
> https://hg.mozilla.org/mozilla-central/file/e4b9b1084292/layout/generic/nsFrame.cpp#l1023
>
> Thanks,
> Ryan
>
> ‐‐‐ Original Message ‐‐‐
> On Monday, January 28, 2019 12:51 PM, Ehsan Akhgari <
> ehsan.akhg...@gmail.com> wrote
On Thu, Jan 24, 2019 at 6:52 AM Andrea Marchesini
wrote:
> I intend to turn "implicit ref=noopener for anchor and area elements for
> target=_blank" on by default in 67. It has been developed behind the
> "dom.targetBlankNoOpener.enabled" preference and enabled in nightly for ~2
> cycles (it
This is indeed one of the cases where the reformat has made things worse.
I think as a couple of people have already said, we'll find that some
people do find these annotations useful, even if they're not always
consistently present.
The path to least resistance for addressing this problem may be
On Mon, Jan 28, 2019 at 10:51 AM Daniel Veditz wrote:
> On Mon, Jan 28, 2019 at 12:57 AM Andrea Marchesini <
> amarches...@mozilla.com> wrote:
>
>> If we try to apply the new cookie policy immediately, 3rd party trackers
>> in opened tabs should switch to a first-party-isolation storage, but
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 Thu, Jan 10, 2019 at 7:27 AM Andrea Marchesini
wrote:
> Summary: Reporting API offers 2 ways to obtain reports: ReportingObserver
> and Report-to Header. I implemented ReportingObserver months ago and I sent
> a separate intent-to-implement email about it. This email is about
> "report-to"
Hi everyone,
I'd like to propose the first modification to our clang-format rules based
on the feedback I've received since the switch to our new coding style from
the SpiderMonkey team.
The problem we're trying to solve is that in code that has nested
preprocessor directives, when the
This project has been a tremendous amount of effort. It started some time
around April last year, I think. This should help fix one of the major
cases where Gecko's performance currently can suffer quite a lot compared
to other engines on certain pages.
Thanks a lot for pushing things through
Hi everyone,
As of Firefox 65 I intend to turn the Storage Access API on by default on
all desktop platforms. It has been developed behind the
dom.storage_access.enabled preference. Other UAs shipping this or intending
to ship it are Safari 12.
*Bug to turn on by default*: link to main relevant
On Mon, Dec 17, 2018 at 1:22 PM Steve Fink wrote:
> In theory, I would definitely prefer if all the code were auto-formatted
> during regular development(*), but in practice the performance means
> it's not as transparent as it needs to be -- I have noticed that since
> enabling the
On Fri, Dec 14, 2018 at 4:55 PM Kartikaya Gupta wrote:
> On Fri, Dec 14, 2018 at 1:58 PM Sylvestre Ledru
> wrote:
> > We have more and more tools at review phase (clang-format, flake8,
> eslint, clang-tidy, codespell, etc) which propose some auto-fixes.
>
> Honestly I find it quite annoying
On Sun, Dec 16, 2018 at 9:08 PM Makoto Kato wrote:
> Hi,
>
> Is Objective-C++ (*.mm) still old format? Or Should I file a bug for it?
>
We didn't include Objective-C++ in the initial reformatting of the tree
mostly to avoid scope creep, but clang-format is well capable of formatting
it.
int hooks which are documented here: <
https://firefox-source-docs.mozilla.org/tools/lint/usage.html#using-a-vcs-hook>.
The only difference is that you should use hooks_clang_format.py as the
file name.
> On Mon, Dec 17, 2018 at 9:22 AM Ehsan Akhgari
> wrote:
> >
> > On Fri,
king sure that
scenarios such as rebasing will also not mess up the formatting of the
commits in your local queue.
>
> On Thu, Dec 13, 2018 at 5:54 PM Ehsan Akhgari
> wrote:
> >
> > Previously I had shied away from ideas similar to (a) or (b) since I
> wasn't sure if that would b
On Thu, Dec 13, 2018 at 6:05 PM Randell Jesup wrote:
> >> tl;dr: I need to figure out how I'm going to dig out of the rebasing
> hole
> >> I'm now in, and could use advice/help, and I think the above sequence
> >> doesn't work for queues of dependent patches.
> >
> >If I'm understanding your
Previously I had shied away from ideas similar to (a) or (b) since I wasn't
sure if that would be what developers would expect and accept, given that
it would cause the change the reviewer sees to no longer match their local
change, which could cause hicups e.g. when trying to find the code that a
On Fri, Nov 30, 2018 at 8:23 PM Ehsan Akhgari
wrote:
> On Fri, Nov 30, 2018 at 4:08 PM Gregory Szorc wrote:
>
>> On Fri, Nov 30, 2018 at 10:00 AM wrote:
>>
>> > Now that all of mozilla-central is been migrated to use clang-format
>> > automated code for
On Fri, Nov 30, 2018 at 4:08 PM Gregory Szorc wrote:
> On Fri, Nov 30, 2018 at 10:00 AM wrote:
>
> > Now that all of mozilla-central is been migrated to use clang-format
> > automated code formatting, the question of what should happen with editor
> > modelines at the top of files should be
On Fri, Nov 30, 2018 at 2:06 PM Nathan Froyd wrote:
> On Fri, Nov 30, 2018 at 1:51 PM Ehsan Akhgari
> wrote:
> > I think these are all great points. It seems like for Emacs, it is not
> > actually necessary to sprinkle modelines across all of the files in your
> &g
On Fri, Nov 30, 2018 at 1:00 PM wrote:
> Now that all of mozilla-central is been migrated to use clang-format
> automated code formatting, the question of what should happen with editor
> modelines at the top of files should be considered.
>
>
On Thu, Nov 29, 2018 at 10:47 PM Emilio Cobos Álvarez
wrote:
> On 11/30/18 2:06 AM, Ehsan Akhgari wrote:
> > On Thu, Nov 29, 2018 at 9:43 AM Emilio Cobos Álvarez
> > wrote:
> >
> >> On 11/29/18 1:38 PM, Sylvestre Ledru wrote:
> >>> This extension w
On Thu, Nov 29, 2018 at 6:27 AM Emilio Cobos Álvarez
wrote:
> Sorry for the lag replying to this.
>
> On 11/13/18 4:35 PM, James Graham wrote:
> > On 11/11/2018 17:57, Emilio Cobos Álvarez wrote:
> >
> >> web-platform-tests: Test coverage for all the values is pre-existing.
> >> There's
On Thu, Nov 29, 2018 at 9:43 AM Emilio Cobos Álvarez
wrote:
> On 11/29/18 1:38 PM, Sylvestre Ledru wrote:
> > This extension will automatically rebase the local changes to avoid
> > conflicts.
>
> Is there a way to do the same for cinnabar users?
>
Yes! Sorry for the delay...
Please check out
On Thu, Nov 29, 2018 at 12:20 PM Boris Zbarsky wrote:
> On 11/29/18 11:40 AM, Ehsan Akhgari wrote:
> > Yes, that is true sadly. But to be fair here, old mq patches that do not
> > apply due to age are already beyond saving with any kind of automated
> > tooling, and the
This short guide should be helpful for Mercurial users:
https://docs.google.com/document/d/13AwAsvKMhH0mflDlfatBqn6LmZHiQih76oxM4zfrPl4
On Thu, Nov 29, 2018 at 11:49 AM Ehsan Akhgari
wrote:
> On Thu, Nov 29, 2018 at 11:44 AM Honza Bambas wrote:
>
>> On 2018-11-29 17:12, Ehsan A
On Thu, Nov 29, 2018 at 11:44 AM Honza Bambas wrote:
> On 2018-11-29 17:12, Ehsan Akhgari wrote:
> > On Thu, Nov 29, 2018 at 8:00 AM Boris Zbarsky wrote:
> >
> >> On 11/29/18 7:38 AM, Sylvestre Ledru wrote:
> >>> This extension will automatical
On Thu, Nov 29, 2018 at 11:30 AM Boris Zbarsky wrote:
> On 11/29/18 11:12 AM, Ehsan Akhgari wrote:
> >* Pull from a pre-reformat of the tree, run ./mach bootstrap to
> install
> > hg-formatsource.
> >* Do a one-time translation of your mq queue to a set of com
On Thu, Nov 29, 2018 at 8:00 AM Boris Zbarsky wrote:
> On 11/29/18 7:38 AM, Sylvestre Ledru wrote:
> > This extension will automatically rebase the local changes to avoid
> > conflicts.
>
> Sylvestre,
>
> Will it also update mq patches, or just in-repo commits?
>
I don't think this extension is
On Thu, Nov 22, 2018 at 4:07 AM Jean-Yves Avenard
wrote:
> Hi
>
> > On 21 Nov 2018, at 3:54 am, Ehsan Akhgari
> wrote:
> >
> >
> > You will break the blame on VCS with this change
> >
> > Yes and no. Of course, just like many tree-wide mass changes
On Thu, Nov 22, 2018 at 10:55 AM Boris Zbarsky wrote:
> On 11/22/18 1:06 AM, Ehsan Akhgari wrote:
> >> Can one do noreferrer with window.open()?
> >>
> >
> > Yes, by passing 'noopener' in the features argument:
> >
> https://html.spec.whatwg.org/mult
On Wed, Nov 21, 2018 at 11:55 PM Boris Zbarsky wrote:
> On 11/21/18 11:50 PM, Ehsan Akhgari wrote:
> > Would it be OK if the answer to that question be "use window.open()"?
>
> Can one do noreferrer with window.open()?
>
Yes, by passing 'noopener' in
On Wed, Nov 21, 2018 at 3:55 PM Boris Zbarsky wrote:
> On 11/21/18 2:22 PM, Daniel Veditz wrote:
> > "opener" doesn't exist
>
> It does in WebKit's proposed changes and in our implementation of them.
>
> > You'd specify a target
> > name other than "_blank" to indicate it's a context you care
(In case the formatting doesn't survive transit, a copy of this note can be
found here:
https://docs.google.com/document/d/1CTaWucldHxEri5BUB1kL4faF4prwPlBa31yHFd-l8uc
.)
TL;DR
To improve developer productivity, we are planning to a) start
automatically formatting all Gecko C++ code with
g ReportingObserver.
>
> c. it's a nice diagnostic tool for websites. In the 'report-to' HTTP
> header, entry-points can be used as communication channel between the
> browser and the server.
>
>
> On Thu, Nov 15, 2018 at 5:25 PM Boris Zbarsky wrote:
>
> > On 11/15/18 9:52
On Wed, Nov 14, 2018 at 11:20 AM Boris Zbarsky wrote:
> On 11/13/18 4:33 AM, Andrea Marchesini wrote:
> > I decided to implement this API, because it is required in the
> > web-platform-tests for FeaturePolicy.
>
> Is it needed for any other reason? If not, this seems like a bug in the
> tests:
On Wed, Nov 14, 2018 at 10:58 AM Tom Ritter wrote:
> On Wed, Nov 14, 2018 at 3:17 PM Ehsan Akhgari
> wrote:
> > What are your plans with regards to implementing the second part? Can
> > these reports be sent cross-origin? (From the spec, it seems like the
> > ans
On Tue, Nov 13, 2018 at 4:33 AM Andrea Marchesini
wrote:
> Reporting API covers 2 different features:
> a. reporting to the current page, via ReportingObserver
> b. reporting to a remote server, known via 'report-to' HTTP header.
> My implementation covers only the first aspect. However I also
On Fri, Nov 2, 2018 at 5:26 PM Emilio Cobos Álvarez
wrote:
> This is mostly to prevent compat headache in mobile, hopefully prevent
> other vendors from shipping new un-spec'd env variables, and encourage
> people to use the fallback value if new environment variables are added
> in the future.
Thanks a lot, this is great news!
What's the process model configuration for this testing platform? Do these
tests run in single process mode or are they running in some e10s like
environment? Is there some documentation that explains what runs in which
process?
Thanks,
Ehsan
On Thu, Nov 1,
Thank you for doing this! I cannot overstate how many times this has
tripped me and others over in the past.
Cheers,
Ehsan
On Thu, Nov 1, 2018 at 8:02 AM Julian Descottes
wrote:
> We are about to land https://bugzilla.mozilla.org/show_bug.cgi?id=1467712
> which changes the behavior of `ok()`
/en-US/docs/Mozilla/Firefox/Privacy/Storage_access_policy
>
> On Wed, Sep 19, 2018 at 10:24 PM Ehsan Akhgari
> wrote:
>
>> Hi everyone,
>>
>> This is a (belated) intent to implement, as well as an intent to ship, a
>> new cookie jar policy to block storage acces
On Thu, Sep 27, 2018 at 11:19 AM Aaron Klotz wrote:
> 1. Automation
> -
>
> If you are doing some kind of automation that waits for the Firefox
> process to finish, you'll find that the initial Firefox process exits
> sooner than the browser, appearing to your script that Firefox is
Hi Randell,
The last part of your email where you suggested this metric could be
proposed for the Performance API WG confused me a bit about its goals. It
seemed to me from the description earlier that the goal behind MID is to
provide a metric useful for browser engineers who would like to
be wonderful to have!
> On Wed, Sep 19, 2018 at 5:05 PM Randell Jesup
> wrote:
>
> > >On Thu, Sep 20, 2018 at 09:22:12AM +1000, Cameron McCormack wrote:
> > >> On Thu, Sep 20, 2018, at 1:52 AM, Ehsan Akhgari wrote:
> > >> > Wh
Hi everyone,
This is a (belated) intent to implement, as well as an intent to ship, a
new cookie jar policy to block storage access to tracking resources. This
work has been under development for several months now and has been tracked
in
On Tue, Sep 18, 2018 at 1:30 AM Randell Jesup wrote:
> >On 9/17/2018 1:31 PM, Botond Ballo wrote:
> >> One potential issue here is that an assertion failure in Nightly
> >> builds might be simultaneously very annoying (because it crashes the
> >> browser of Nightly users every time it occurs)
On Fri, Sep 14, 2018 at 2:25 PM Boris Zbarsky wrote:
> On 9/14/18 1:58 PM, Andrea Marchesini wrote:
> > DevTools bug: No devtools support.
>
> Seems like devtools might be useful for answering questions like "what
> is the feature policy for this page and why?" given the complexity of
> feature
On Thu, Sep 13, 2018 at 9:40 AM john.bieling--- via dev-platform <
dev-platform@lists.mozilla.org> wrote:
> I encountered something strange. I am on TB60 trying to use the Fetch API.
>
> I create a GET or POST request without authentication and get back a 401
> from the server and use
>
>
Hi everyone,
As someone who cares a lot about code review (both as a developer and as a
reviewer), I care a lot about the tools I work with and the workflows I’ve
built around them over the years. I’m sure I’m not the only one there.
What Mark wrote about below brings changes to some parts of
On Wed, Sep 12, 2018 at 3:47 AM Anne van Kesteren wrote:
> On Tue, Sep 11, 2018 at 9:06 PM Ehsan Akhgari
> wrote:
> > Please note that Firefox will grant storage access permissions
> > automatically under certain circumstances for web compatibility reasons,
> so
> &g
On Mon, Sep 10, 2018 at 11:19 AM James Graham
wrote:
> On 07/09/2018 21:27, Ehsan Akhgari wrote:
>
> > Very cool, I did not know this! It seems like test_driver.bless() is
> > what we need here for simulating a user activation gesture.
> >
> > However it so
On Sun, Sep 9, 2018 at 5:10 AM Mike O'Neill wrote:
> This is great but I have a couple queries.
> >
> >In our implementation, once Storage Access API grants storage access,
> >all existing third-party iframes on the same first party will receive
> that
> >storage access, whereas in
On Fri, Sep 7, 2018 at 2:49 PM James Graham wrote:
> > web-platform-tests: Our implementation unfortunately doesn’t come with
> > web-platform-tests, for two reasons. One is that there is currently no
> way
> > to mock user gestures in web platform tests [4], and the second reason is
> > that
On Fri, Sep 7, 2018 at 2:32 PM Tom Ritter wrote:
> On Fri, Sep 7, 2018 at 12:54 PM, Ehsan Akhgari
> wrote:
>
>>In our implementation, once the Storage Access API grants storage
>>access, all newly created third-party iframes of the same origin will
>>
Hi everyone,
As we recently announced [0], we are working on a number of new
anti-tracking features which are intended to change the current approach in
Firefox with regards to how user’s data is shared with third-party trackers
as the user browses the web.
In the old world (the status quo for
This is great work, thanks a lot, Nick!
On Wed, Aug 15, 2018 at 5:39 AM Nicholas Nethercote
wrote:
> Bug 1477627 converted a hot hash table from PLDHashTable to
> mozilla::HashSet and appears to have sped up cycle collection in some cases
> by 7%. If you know of another PLDHashTable that is
On Fri, Jul 20, 2018 at 5:00 AM, Jonathan Kew wrote:
> On 20/07/2018 03:17, Jeff Gilbert wrote:
>
>> Using a classic read/write exclusive lock, we would only every contend
>> on read+write or write+write, which are /rare/.
>>
>
> Indeed, that's what I envisage we'd want. The -vast- majority of
On Fri, Jun 29, 2018 at 2:36 PM, smaug wrote:
> On 06/29/2018 05:58 PM, Boris Zbarsky wrote:
>
>> On 6/29/18 10:30 AM, Nathan Froyd wrote:
>>
>>> Given the language-required qualification for
>>> `enum class` and a more Rust-alike syntax, I would feel comfortable
>>> with saying CamelCase `enum
Hi everyone,
This is a quick note to remind you of the adverse effects of IPC messages
that can be sent from the content process to the parent process especially
from web content Javascript accessible APIs.
Let's say you have a JS callable function foo() which sends the IPC message
MsgBar to the
On Wed, May 30, 2018 at 5:02 PM, Anthony Jones wrote:
> On Thursday, 31 May 2018 02:44:51 UTC+12, Tom Ritter wrote:
> > Oh. Are we doing this rustc inlining development on a particular old
> > version of clang? I'm not even close to getting CFI ready but I'm
> > basically working off llvm
Hi Masayuki,
First of all, thank you for taking on this task. I have a few questions.
* What does the backwards compatibility story for these changes look like?
Would we end up for example throwing exceptions or returning a different
value from execCommand/queryCommandState/etc for one of the
1 - 100 of 1215 matches
Mail list logo
