Re: Rust and Servo training sessions at Whistler
Does the Servo session (which is earlier than the Rust session) require prior experience with Rust? Thanks, Jim On 6/8/15 3:44 PM, Lars Bergstrom wrote: The Research team will be holding a pair of 3 hour training sessions, with one on the new web rendering engine, Servo, and one on the new systems language it is implemented in, Rust. These sessions will have both presentation components and a large hands-on piece with exercises to do on your laptops. The Rust session will also have some content on building Rust code into Gecko. If you are interested in attending, please sign up on the Sched links below (you will have to log in and then click the “Add To My Sched” button). The numbers will help us figure out how many USB sticks to bring, how many people we need to have staffing the training, whether there is enough space in the booked room, whether we have enough stickers, etc. The Platform admins and managers have helped ensure that the Rust session will not conflict with any team’s meetings and that the Servo one will not conflict with meetings for teams that work on browser features, so you shouldn’t need to worry about something getting booked over them. Servo - Wednesday, 1–4 PM: http://sched.co/3ZQn http://sched.co/3ZQn Rust - Thursday, 1–4 PM: http://sched.co/3ZQp http://sched.co/3ZQp Please don’t hesitate to reach out if there are specific things you’d like to see us cover, as we’re making up the training materials right now. Thanks! - Lars ___ 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: The War on Warnings
Last time I looked at whitelisting non-fatal assertions, there was only the option to accept up-to a number of assertions. Have I missed something? Because a blank check to sweep assertions under the carpet is really an awful mechanism. Now, I fully agree that warnings that are not whitelisted should most likely cause real assertion failures. Cheers, David On 08/06/15 19:09, Ehsan Akhgari wrote: On 2015-06-05 6:08 AM, David Rajchenbach-Teller wrote: This API covers all the needs I have encountered for warnings so far in JS code. I don't think it's terribly different in C++ code. For C++ non-fatal assertions, we already have a mechanism similar to this (but it doesn't rely on the exact message printed in the warning, of course.) I prefer to not try to do what you are doing for C++ warnings, because if there are ones that we should really not trigger in a test, those should be promoted to be assertions, and then we would be able to rely on the existing mechanisms to catch them during test runs. Cheers, Ehsan -- David Rajchenbach-Teller, PhD Performance Team, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: nsIAboutModule::URI_SAFE_FOR_UNTRUSTED_CONTENT and add-on chrome
To specifically answer Geoff's question - the difference you're seeing between JS/CSS and docshell loads is that the former end up with the principal of the loader, whereas docshell loads end up with the principal of the loadee. Allowing content to load a chrome-privileged window is super dangerous, which is why it's forbidden. On Mon, Jun 8, 2015 at 8:18 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 6/8/15 6:57 AM, Geoff Lankow wrote: If I have an about page marked URI_SAFE_FOR_UNTRUSTED_CONTENT, it happily loads css/js from chrome://browser (in fact, about:home does this), but throws a security error loading from chrome://foo. Is this intentional? Whether untrusted content can load CSS/JS from chrome://something depends on whether the chrome://something has opted into allowing that. This allows extensions to expose only the things they want to expose. See also https://developer.mozilla.org/en-US/docs/Chrome_Registration#contentaccessible In this case, browser/base/jar.mn has: % content browser %content/browser/ contentaccessible=yes So yes, the behavior you see is intentional if the registration for chrome://foo does not explicitly expose its stuff to untrusted content. That said, it's pretty weird to me that we're exposing the entirety of chrome://browser like that. Seems like we should scope it down. -Boris ___ 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: The War on Warnings
Hi,
On 2015/06/06 2:39, Eric Rahm wrote:
On Friday, June 5, 2015 at 8:23:53 AM UTC-7, ISHIKAWA,chiaki wrote:
After coping with voluminous messages in C-C TB |make mozmill| test
suite log [much smaller volume than full FF logs],
I think we should have NS_INFORMATION() macro that
prints out an information for someone who is developing code and
just wants to know how the code is doing.
I suppose we could add yet another macro, but really this sounds like a use
case for:
MOZ_LOG(myModule, LogLevel::Info, Dev message!);
which could then be enabled with something like:
|NSPR_MODULES=myModule:3 ./mach run|
Thank you for the tips.
(I was referring to *NS*_INFORMATION() since
when I tried to use MOZ_ABORT() or something in some test codes,
I could not compile and link them and learned some MOZ_* macros and NS_*
macros don't mix very well during linking(?).)
Anyway, I am a little confused since MOZ_LOG() is very new.
What is the first argument to the following code?
|MOZ_LOG(myModule, LogLevel::Info, Dev message!);|
Looking at how PR_LOG() was called with PRLogModuleInfo,
typedef struct PRLogModuleInfo {
const char *name;
PRLogModuleLevel level;
struct PRLogModuleInfo *next;
} PRLogModuleInfo;
Is |myModule| it declared as
PRLogModuleInfo myModule;
is passed to as the first argument of MOZ_LOG().?
But it sounds as if we should stay away from PRLog* data structure.
Or is it simply anything (and stringified internally) that
will be specified in environmental variable later?
It might be useful to eventually add a |MOZ_LOG_IF| to make things easier.
Yes, for readability, we need some creative macros.
1576 [10262] WARNING: '!mMainThread', file
/REF-COMM-CENTRAL/comm-central/mozilla/xpcom/threads/nsThreadManager.cpp, line
We're working on this in bug 1171716, it's related to cycle collection on
shutdown.
Anyway, I agree that we should simply try to attack the top entries
first to figure out whether they are indication of genuine issues/bugs, etc.
Yes! Please file blocking bugs for the top c-c entries against bug 765224.
I will try to do so.
Eventually we could cut down the number to manageable size.
(At near the beginning of 2013, the list became only about a dozen items
long, but started to grow again. In a sense it reflects the desire of
code authors to catch strange conditions, but I agree we must keep on
looking at the logs and do something about the top offenders in the log
list.)
It might be nice to create a very simple start/stop test that just makes sure
there are no warnings so that we can avoid regressing that in the future.
Sounds a sensible idea.
TIA
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: The War on Warnings
On 2015-06-05 6:08 AM, David Rajchenbach-Teller wrote: This API covers all the needs I have encountered for warnings so far in JS code. I don't think it's terribly different in C++ code. For C++ non-fatal assertions, we already have a mechanism similar to this (but it doesn't rely on the exact message printed in the warning, of course.) I prefer to not try to do what you are doing for C++ warnings, because if there are ones that we should really not trigger in a test, those should be promoted to be assertions, and then we would be able to rely on the existing mechanisms to catch them during test runs. Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The War on Warnings
On 6/8/15 4:28 PM, David Rajchenbach-Teller wrote: Last time I looked at whitelisting non-fatal assertions, there was only the option to accept up-to a number of assertions. You can specify an exact number or a range. But you're right that you can't specify the assertion text involved... -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: nsIAboutModule::URI_SAFE_FOR_UNTRUSTED_CONTENT and add-on chrome
Ah, perfect. Thanks Boris. On 09/06/15 03:18, Boris Zbarsky wrote: On 6/8/15 6:57 AM, Geoff Lankow wrote: If I have an about page marked URI_SAFE_FOR_UNTRUSTED_CONTENT, it happily loads css/js from chrome://browser (in fact, about:home does this), but throws a security error loading from chrome://foo. Is this intentional? Whether untrusted content can load CSS/JS from chrome://something depends on whether the chrome://something has opted into allowing that. This allows extensions to expose only the things they want to expose. See also https://developer.mozilla.org/en-US/docs/Chrome_Registration#contentaccessible In this case, browser/base/jar.mn has: % content browser %content/browser/ contentaccessible=yes So yes, the behavior you see is intentional if the registration for chrome://foo does not explicitly expose its stuff to untrusted content. That said, it's pretty weird to me that we're exposing the entirety of chrome://browser like that. Seems like we should scope it down. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Rust and Servo training sessions at Whistler
Jim, We won’t get into anything that requires prior Rust experience during the Servo session - the focus is intended to be more on architecture, web platform compat, and with a bit of poking around to make small changes (e.g., either fixing or breaking WPT and CSS WG ref tests with tiny code changes). Ideally, we would have had the Rust one first, but the Thursday slot had fewer conflicts and there were more groups interested in the Rust training than the Servo one. - Lars On Jun 8, 2015, at 5:15 PM, Jim Chen nc...@mozilla.com wrote: Does the Servo session (which is earlier than the Rust session) require prior experience with Rust? Thanks, Jim On 6/8/15 3:44 PM, Lars Bergstrom wrote: The Research team will be holding a pair of 3 hour training sessions, with one on the new web rendering engine, Servo, and one on the new systems language it is implemented in, Rust. These sessions will have both presentation components and a large hands-on piece with exercises to do on your laptops. The Rust session will also have some content on building Rust code into Gecko. If you are interested in attending, please sign up on the Sched links below (you will have to log in and then click the “Add To My Sched” button). The numbers will help us figure out how many USB sticks to bring, how many people we need to have staffing the training, whether there is enough space in the booked room, whether we have enough stickers, etc. The Platform admins and managers have helped ensure that the Rust session will not conflict with any team’s meetings and that the Servo one will not conflict with meetings for teams that work on browser features, so you shouldn’t need to worry about something getting booked over them. Servo - Wednesday, 1–4 PM: http://sched.co/3ZQn http://sched.co/3ZQn Rust - Thursday, 1–4 PM: http://sched.co/3ZQp http://sched.co/3ZQp Please don’t hesitate to reach out if there are specific things you’d like to see us cover, as we’re making up the training materials right now. Thanks! - Lars ___ 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: The War on Warnings
The question is what is best: ignored warnings or ignored intermittent oranges? I assume that the latter have the best chance of being eventually fixed, but I'm not sure. On 05/06/15 18:17, Ryan VanderMeulen wrote: Uncaught Promise rejections were made fatal and for the most part go ignored when they fail intermittently. I'm not a huge fan of adding more ways for tests to fail if people aren't willing to actually do something about it when they do. -Ryan -- David Rajchenbach-Teller, PhD Performance Team, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Way to discarding xul is raising HTML.
Right. Not supported yet. On Mon, Jun 8, 2015 at 11:13 AM, 罗勇刚(Yonggang Luo) luoyongg...@gmail.com wrote: I also found in pure html window, there is no way to add support for context menu. And also popup. 2015-06-08 12:17 GMT+08:00 Paul Rouget p...@mozilla.com: B2G on desktop only uses HTML. OS integration is poor, but we are working on it. See the larch branch (https://hg.mozilla.org/projects/larch). We are working on OS X support first. For session restore, see bug 1033999. On Fri, Jun 5, 2015 at 8:02 PM, 罗勇刚(Yonggang Luo) luoyongg...@gmail.com wrote: At the current time, pure html window doesn't support for session and other things. Such as setting the whole html's background to be transparent with the operating system. If we want to remove XUL completely from Mozilla source tree, what's left to do? -- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- Paul -- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo -- Paul ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
nsIAboutModule::URI_SAFE_FOR_UNTRUSTED_CONTENT and add-on chrome
If I have an about page marked URI_SAFE_FOR_UNTRUSTED_CONTENT, it happily loads css/js from chrome://browser (in fact, about:home does this), but throws a security error loading from chrome://foo. Is this intentional? Should I be filing a bug somewhere? GL ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Way to discarding xul is raising HTML.
I also found in pure html window, there is no way to add support for context menu. And also popup. 2015-06-08 12:17 GMT+08:00 Paul Rouget p...@mozilla.com: B2G on desktop only uses HTML. OS integration is poor, but we are working on it. See the larch branch (https://hg.mozilla.org/projects/larch). We are working on OS X support first. For session restore, see bug 1033999. On Fri, Jun 5, 2015 at 8:02 PM, 罗勇刚(Yonggang Luo) luoyongg...@gmail.com wrote: At the current time, pure html window doesn't support for session and other things. Such as setting the whole html's background to be transparent with the operating system. If we want to remove XUL completely from Mozilla source tree, what's left to do? -- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- Paul -- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Per-test chaos mode now available, use it to help win the war on orange!
On Thursday, June 4, 2015 at 5:30:32 PM UTC-4, Chris Peterson wrote: Will chaos mode enabled tests run on Try and release branches? If a test has chaos mode enabled, then it will have chaos mode enabled on all branches, including Try and release branches. We don't know if chaos mode test failures are representative of real bugs, but could chaos mode hide bugs that only reveal themselves when users run without chaos mode? It's possible but I think this is pretty unlikely. In all of the callsites I checked, chaos mode is used to push us off the beaten path with respect to code execution flow, but it does so randomly and so in some cases we should take the same path as if chaos mode were disabled. kats ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
FW: [Firefox Desktop] Issues found: June 1st to June 5th
From: Firefox-qe [mailto:firefox-qe-boun...@mozilla.org] On Behalf Of Florin Mezei Sent: Monday, June 08, 2015 5:01 PM To: firefox...@mozilla.org; dev-platf...@mozilla.org; firefox-...@mozilla.org Cc: 'Lawrence Mandel' Subject: [Firefox Desktop] Issues found: June 1st to June 5th Hi everyone, You can find below the list of new issues found and filed by the Desktop Manual QA team last week (Week 23: June 01 - June 05). Additional details on the team's priorities last week, as well as the plans for the current week can be found at: https://etherpad.mozilla.org/DesktopManualQAWeeklyStatus. Release Channel: No bugs. Beta Channel: NEW Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1170540 1170540 - openH264 plugin no longer installed after restarting the browser * Regression: Yes - bug 1156566 https://bugzilla.mozilla.org/show_bug.cgi?id=1156566 * Severity: Normal. NEW Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1170486 1170486 - Candy Crush Saga is not loading on the first try when using a new profile * Regression: Yes - bug 1151804 https://bugzilla.mozilla.org/show_bug.cgi?id=1151804 * Severity: Normal. NEW Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1171948 1171948 - Hang on http://dailycaller.com/section/entertainment/ * Regression: No. * Severity: Normal. NEW Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1171877 1171877 - [Windows 10] Taskbar context menu is not working properly. * Regression: No. * Severity: Normal. NEW Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1171894 1171894 - Reader View icon is shown for several apple.com trailers * Regression: No. * Severity: Normal. Aurora Channel: NEW Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1171359 1171359 - Selecting Not now button which correspond with Restart option makes the add-on icon from location bar to disappear * Regression: No. * Severity: Normal. Nightly Channel: RESO Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1170946 1170946 - Pressing Measure in quick succession drastically increases the occupied memory. * Regression: No. * Severity: Normal. NEW Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1171381 1171381 - Share Link pop-up misplaced when conversation window is detached and resized * Regression: No. * Severity: Normal. NEW Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1171496 1171496 - crash in mozilla::gmp::GMPParent::ChildTerminated() * Regression: No. * Severity: Critical. NEW Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1171925 1171925 - Name and favicon from conversation window are redirecting to shared webpage in context * Regression: No. * Severity: Normal. ESR Channel: NEW Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1170516 1170516 - ESR 31.7.0 is not signed on Mac Os X 10.10 * Regression: No. * Severity: Normal. Regards, Florin. Florin Mezei | QC Team Lead SOFTVISION | 57 Republicii Street, 400489 Cluj-Napoca, Romania Email: mailto:fme...@softvision.ro fme...@softvision.ro | Web: http://www.softvision.ro/ www.softvision.ro The content of this communication is classified as SOFTVISION Confidential and Proprietary Information. ___ Firefox-qe mailing list firefox...@mozilla.org https://mail.mozilla.org/listinfo/firefox-qe ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: mozglue.dll!jemalloc_crash
On Friday, 5 June 2015 20:42:29 UTC+5:30, Kyle Huey wrote: You need to look further up the stack. jemalloc_crash is not an interesting stack frame. - Kyle On Fri, Jun 5, 2015 at 8:05 AM, Meenakshi Shankar hifromme...@gmail.com wrote: Hi, We are using Firefox SDKS for our FF extension (libs generated after compiling Firefox 39 beta 2 source using start-shell-msvc2013). With our extension enabled in Firefox, we receive a mozglue.dll!jemalloc_crash(...) With reference to bugzilla 1168291 we used mozcrt.lib for replacing mozalloc.lib, but still we see the crash in mozglue.dll. Also similar crash reported in bugzilla 1130180 and 1114791. Can anyone kindly let us know if this crash is fixed. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform Hi Kyle, Thanks for the reply. While analysing the mozglue.dll!jemalloc_crash(...) we observed the crash after hitting the add resource instance calls (_AtlBaseModule.AddResourceInstance). Hence we would like to understand if there is any changes with respect to loading resource protocols. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Per-test chaos mode now available, use it to help win the war on orange!
On Thursday, June 4, 2015 at 6:15:35 PM UTC-4, Chris AtLee wrote: Very interesting, thank you! Would there be a way to add an environment variable or harness flag to run all tests in chaos mode? There isn't at the moment but one can definitely be added if there is a use for it. At the moment the easiest way to enable chaos mode globally is to change the value of sChaosFeatures in ChaosMode.h and recompile. kats ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: nsIAboutModule::URI_SAFE_FOR_UNTRUSTED_CONTENT and add-on chrome
On 6/8/15 6:57 AM, Geoff Lankow wrote: If I have an about page marked URI_SAFE_FOR_UNTRUSTED_CONTENT, it happily loads css/js from chrome://browser (in fact, about:home does this), but throws a security error loading from chrome://foo. Is this intentional? Whether untrusted content can load CSS/JS from chrome://something depends on whether the chrome://something has opted into allowing that. This allows extensions to expose only the things they want to expose. See also https://developer.mozilla.org/en-US/docs/Chrome_Registration#contentaccessible In this case, browser/base/jar.mn has: % content browser %content/browser/ contentaccessible=yes So yes, the behavior you see is intentional if the registration for chrome://foo does not explicitly expose its stuff to untrusted content. That said, it's pretty weird to me that we're exposing the entirety of chrome://browser like that. Seems like we should scope it down. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
