[desktop] Bugs logged by Desktop Release QA in the last 7 days

Hello, Here's the list of new issues found and filed by the Desktop Release QA team last two weeks. Additional details on the team's priorities last week, as well as the plans for the current week are available at: https://tinyurl.com/ya5okvx7 Bugs logged by Desktop Release QA in the last 7 da

Re: Cookie policy/permission in live documents - proposal

On Fri, Jan 25, 2019 at 8:50 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 th

Re: Cookie policy/permission in live documents - proposal

On Fri, Jan 25, 2019 at 11:55 PM Ehsan Akhgari wrote: > 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 ha

Re: Cookie policy/permission in live documents - proposal

Thanks for writing this up and adding the great explanations, Andrea! I think your proposal has a lot of benefits and I don't have any major concerns about it, I would just like to add a few comments: Just to reiterate, per your proposal the cookie policy (network.cookieBehavior pref) and permiss

Does mozilla allow to modify the core strings in it.

Is it possible to add an extra variable to mozilla string(nsTStringRepr). I added a bool variable to nsTStringRepr class in Xpcom/Strings/ While building the build I got static Assertions like below /Users/pavan-6853/Desktop/MOZB

Does mozilla allow modification of Strings

Is it possible to add an extra variable to mozilla string(nsTStringRepr). I added a bool variable to nsTStringRepr class in Xpcom/Strings/ While building the build I got static Assertions like below /User/Desktop/MOZ

Re: Does mozilla allow modification of Strings

There are probably two different issues. On 1/28/19 1:51 PM, edusubscr...@gmail.com wrote: > > > Is it possible to add an extra variable to mozilla string(nsTStringRepr). > > > I added a bool variable to nsTStringRepr class in Xpcom/Strings/ > > While building the build I got stati

Re: Does mozilla allow modification of Strings

On 1/28/19 7:51 AM, edusubscr...@gmail.com wrote: Building was successful. I'm really surprised the static assert at https://searchfox.org/mozilla-central/rev/4faab2f1b697827b93e16cb798b22b197e5235c9/dom/bindings/FakeString.h#146-147 did not trigger, given the changes you described... -Bori

Re: Does mozilla allow modification of Strings

On 1/28/19 10:30 AM, Nanday Dan wrote: Sorry, I forgot to mention that I commented those lines too. If you comment those lines, you will likely end up with code reading random values for your boolean at best and crashing at worst (if you added the boolean at the end; if not, it's just all goi

Re: Cookie policy/permission in live documents - proposal

On Mon, Jan 28, 2019 at 12:57 AM Andrea Marchesini 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 they > could also have already data in memory (user-tokens), and populate the new > cookie ja

Re: Cookie policy/permission in live documents - proposal

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 they

PSA: New Multi-store Telemetry allows easier re-use of probes in multiple pings

Late in 2018 we landed a basic implementation of the Telemetry multi-store. Telemetry multi-store allows the re-use of probes across multiple pings, with each ping having their own schedule to be sent. It ships in Firefox 65. Overview The lifetime of Telemetry probes (scalars & histograms) and t

PSA: Inadvertently exporting third-party symbols

Hi, As importing third-party code into libxul seems to be pretty popular, I wanted to point out something that's easy to overlook. Libraries usually have code that goes like: #ifdef _WIN32 #define MYLIB_EXPORT __declspec(dllexport) #else #define MYLIB_EXPORT __attribute__((visibility("default"))

removing blank lines at beginnings and ends of JS blocks

Developers, This week I plan to remove blank lines at the beginnings and ends of JS blocks and update the global eslint configuration file to prohibit them by landing the patch in bug 1518283 . Note that I'm not removing all blank lines,

Re: Does mozilla allow modification of Strings

On Mon, Jan 28, 2019 at 02:05:18PM +0100, Emilio Cobos Álvarez wrote: There are probably two different issues. On 1/28/19 1:51 PM, edusubscr...@gmail.com wrote: Is it possible to add an extra variable to mozilla string(nsTStringRepr). I added a bool variable to nsTStringRepr class

Re: C++ method definition comments

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

Re: Does mozilla allow modification of Strings

On Mon, Jan 28, 2019 at 04:51:12AM -0800, edusubscr...@gmail.com wrote: Is it possible to add an extra variable to mozilla string(nsTStringRepr). I added a bool variable to nsTStringRepr class in Xpcom/Strings/ As something of a side note, the general way to do this is to add a new data or

Re: Intent to ship: implicit rel=noopener for target=_blank on anchor and area elements

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 land

Re: C++ method definition comments

I would much rather revert to: /*static*/ void Foo::Bar() The Foo::Bar is the most relevant part of that whole expression, which makes it nice to keep up against the start of the line. In a clang-format world, we should feel more free to make such deviations from Google Style, since it's all hand

PSA: 64-bits Windows build are now the default on 64-bits Windows

Hi, As of bug 1522354, now on autoland, hopefully merged in a few hours, the default build you get on a 64-bits Windows machine will be 64-bits, instead of 32-bits like it had been forever. If you do wish to do a 32-bits build on a 64-bits Windows machine, you can add: ``` ac_add_options --targe

Re: C++ method definition comments

Yeah, personally I have found them be useful and don't have an issue with keeping them. I just wasn't sure if that was a common experience. So for converting from C-style to C++-style, that would be: /* static */ void Foo::Bar() { ... } // static void Foo::Bar() { ... } I think that would be

Heads up: Fluent will now block layout

Hi all, We've just landed a pretty important change to how we localize our UI [0]. Starting from this week (including 66), Fluent (async and sync) will now block layout in all three of XUL/XHTML and HTML. That means that flashes of untranslated content (FOUC) should not be possible anymore. P

Re: C++ method definition comments

Just a thought: Would it be worth considering a blank macro, e.g.: static void foo(); DECLARED_STATIC void foo() {...} On top of not being confused with other comments around, it could be clang-checked so it's never wrong. (And maybe eventually enforced, like MOZ_IMPLICIT is.) Cheers, Gerald O

PSA: Major ChromeUtils.import() API change

As of bug 1514594, the behavior ChromeUtils.import() API has changed in order to avoid touching the caller's global scope, or returning the imported module's global scope. In short, where you previously wrote: ChromeUtils.import("resource://gre/modules/Services.jsm"); You should now write som

Fwd: Intent to Desupport: Fennec Automated Updates (when Sideload Installed)

CC'ing dev-platform, since dev-planning got blackholed with my message. -- Forwarded message - From: Justin Wood Date: Mon, Jan 28, 2019 at 3:36 PM Subject: Intent to Desupport: Fennec Automated Updates (when Sideload Installed) To: planning , firefox-ci < firefox...@mozilla.com>,

Re: PSA: Major ChromeUtils.import() API change

On Mon, Jan 28, 2019 at 04:50:28PM -0800, Kris Maglione wrote: Whatever else this whole process accomplishes, it will have the major side-effect of making our system JS code much more JIT-friendly, and in many cases, some orders of magnitude faster. Since there's been some question about my "o

Re: PSA: Major ChromeUtils.import() API change

On Tue, Jan 29, 2019 at 5:51 AM Kris Maglione wrote: > To begin with, the weirdness of our JSM scopes makes a fair amount of our > system code un-JITtable, which should be enough on its own. In case people are wondering: un-JITtable applies to Ion, the optimizing JIT. The Baseline JIT is able t