Stop including nsIPresShell.h, include mozilla/PresShell.h instead
Hi, I'm trying to get rid of nsIPresShell. nsIPresShell.h is anyway included by mozilla/PresShell.h. So, even if you use only nsIPresShell newly, please include mozilla/PresShell.h instead. FYI: Currently, Document::GetPresShell(), nsPresContext::GetPresShell(), nsPresContext::PresShell(), nsFrameSelection::GetPresShell(), Selection::GetPresShell(), KeyframeEffect::GetPresShell(), EditorBase::GetPresShell() and EditorEventListener::GetPresShell() return mozilla::PresShell* rather than nsIPresShell*. So, when you use them, you can now use PresShell* or RefPtr for storing the result. I'll keep changing other GetPresShell() methods too when I have time, but of course, you're welcome if you do that instead of me ;-) Regards, -- Masayuki Nakano Software Engineer, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Limit the maximum life-time of cookies set through document.cookie to seven days
Hi, is there an expected date for the cookie change to go to production? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: MOZ_DBG
I just landed support for MOZ_DBG for nsIFile (shows the path of the file)
and nsIURI (shows the uri spec) onto inbound.
On Sat, Mar 30, 2019 at 8:04 AM Dave Townsend wrote:
> This sounds excellent. I think on Monday I'll go right to work making this
> work for URIs which are probably the things I end up logging the most from
> C++.
>
> On Fri, Mar 29, 2019 at 11:16 PM Cameron McCormack wrote:
>
>> Lately I've been finding Rust's dbg!() macro[1] useful for quick
>> debugging. Its main usefulness is in avoiding the need to extract out an
>> expression into a separate variable just so that you can print out its
>> value and then use the value in its original context.
>>
>> I wanted something similar for C++, so in bug 1538081, which just landed
>> on autoland, I've added the MOZ_DBG macro.
>>
>> MOZ_DBG can be added around almost any kind of expression[2], as long as
>> there is an operator<<(ostream&, ...) defined for its type. I added
>> operator<< definitions for nsAString, nsACString, mozilla::Span, nsTArray,
>> mozilla::Array, and T[N], since they seemed useful. And as a special case,
>> if you wrap MOZ_DBG around a pointer value, then it will use the operator<<
>> of the dereferenced object (if the operator<< exists, and the pointer is
>> non-null), and otherwise just prints out the pointer value. The output
>> goes to stderr.
>>
>> The macro is defined in mfbt/DbgMacro.h, but I've included it into
>> nsDebug.h, so that it should be available in most files without needing to
>> explicitly #include . It's available in non-DEBUG
>> builds, but not in MOZILLA_OFFICIAL builds.
>>
>> Example:
>>
>> nsTArray numbers;
>> MOZ_DBG(numbers = { MOZ_DBG(123 * 1), MOZ_DBG(123 * 2) });
>> MOZ_DBG(numbers[MOZ_DBG(numbers.Length() - 1)]);
>> MOZ_DBG(numbers) = { 789 };
>> MOZ_DBG(numbers);
>>
>> Output:
>>
>> [/path/to/file.cpp:319] 123 * 1 = 123
>> [/path/to/file.cpp:319] 123 * 2 = 246
>> [/path/to/file.cpp:319] numbers = { MOZ_DBG(123 * 1), MOZ_DBG(123 * 2)
>> } = [123, 246]
>> [/path/to/file.cpp:320] numbers.Length() - 1 = 1
>> [/path/to/file.cpp:320] numbers[MOZ_DBG(numbers.Length() - 1)] = 246
>> [/path/to/file.cpp:321] numbers = [123, 246]
>> [/path/to/file.cpp:322] numbers = [789]
>>
>> There is also a macro MOZ_DEFINE_DBG, which can be used to define an
>> operator<< for a class. It's like a poor imitation of #[derive(Debug)].
>>
>> Example:
>>
>> struct Point {
>> int x;
>> int y;
>>
>> MOZ_DEFINE_DBG(Point, x, y)
>> };
>>
>> Point p{10, 20};
>> MOZ_DBG(p);
>>
>> Output:
>>
>> [/path/to/file.cpp:100] p = Point { x = 10, y = 20 }
>>
>>
>> [1] https://doc.rust-lang.org/stable/std/macro.dbg.html
>> [2] One specific case where it won't work is if you are wrapping it
>> around a prvalue being used to initialize an object, and the type of that
>> value is something that doesn't have a copy or move constructor available.
>> Such types should be rare, though, and you'll get a compiler error if you
>> try.
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Creating a new mach command for adding tests
On 02/04/2019 19:11, Brian Grinstead wrote: I don't think that having papercuts in the workflow for writing one type of test is the right way to nudge developers into writing another type. It also doesn't seem effective - otherwise people would be using the wpt-create tool to avoid jumping through hoops to add a mochitest. To be clear, my intent was not to add papercuts to any workflow; I'd really like all our developer workflows to be as ergonomic as possible, and adding better tooling to help people create tests seems like a great idea. That said, there's a pattern that we've often fallen into where we make broadly applicable improvements to only a single testsuite — often mochitest — and then consider it to be job done. Although each change individually is small, over time it adds up and re-enforces an implied hierarchy of testsuites that doesn't match current best practices. That said, given there’s already a convention for this perhaps the tool as-is would be better named `./mach mochitest-create`. Based on Steve’s suggestion, if we did want a single API we could do something like: # Attempt to automatically determine the type of test (mochitest-chrome, xpcshell, wpt, etc) `./mach addtest path/to/test` # If you want to pass extra arguments specific to that type, then you use a subcommand: `./mach addtest mochitest --flavor=chrome toolkit/components/windowcreator/test/test_chrome.html` `./mach addtest wpt testing/web-platform/tests/accelerometer/test.html --long-timeout` I think the idea of a single mach command for test creation that, as far as possible, guesses the test type from its location is great. I'd be happy to provide whatever support is needed to make this replace the wpt-specific command. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Improving our usage of Bugzilla
Le 03/04/2019 à 11:12, Axel Hecht a écrit : Am 02.04.19 um 19:24 schrieb Sylvestre Ledru: Because I had a few discussions about task vs enhancement, a good way to make the difference between the two use cases is: If I ever need help with this bug, should it come from someone in Product or an EPM? Can I ask for clarification? Is it task - EPM help enhancement - Product help Correct, sorry for the mix. Tasks are more engineering focus. Enhancements are usually feature requests. But I agree that it isn't always easy to decide (example: performance). BTW, the current classification has been done using some heuristics (example: if the severity was enhancement, it is easy) but also some machine learning to classify the rest. Cheers, Sylvestre ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Improving our usage of Bugzilla
Am 02.04.19 um 19:24 schrieb Sylvestre Ledru: Because I had a few discussions about task vs enhancement, a good way to make the difference between the two use cases is: If I ever need help with this bug, should it come from someone in Product or an EPM? Can I ask for clarification? Is it task - EPM help enhancement - Product help or the other way around? As you listed them the other way around, and that's not how I'd line them up. Axel ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
