Help: why won't Thunderbird display mail in mochitest conditions?
Hi Over the past year or so, I've been adding mochitests for new Thunderbird features. It's recently occurred to me that in a mochitest, Thunderbird does not display mail messages. Not even the message header list, just a blank rectangle where the message should be. Obviously this is quite important as displaying messages is Thunderbird's primary function. But I don't understand the reason. I expect that it has something to do with message URLs, which are of the form mailbox:///path/to/mailbox?number=1234. I know that mochitest does things to network access to prevent tests from accessing the internet, but that doesn't seem to be the reason as I can load the URL using fetch. Is there some logic in docshell that behaves differently in a test? As far as I can work out, this code [1] is a part of the loading process, and if docShell->LoadURI fails that would explain why nothing further happens. (IANA core hacker, excuse my ignorance!) GL [1] https://searchfox.org/comm-central/rev/753e6d9df9d7b9a989d735b01c8b280eef388bab/mailnews/local/src/nsMailboxService.cpp#205 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: multi-keyword values on the CSS 'display' property
On 8/26/19 4:42 PM, Boris Zbarsky wrote: On 8/19/19 3:42 PM, Mats Palmgren wrote: Sure. I'm just saying that I suspect some of the combinations may be hard to implement using anon boxes, depending on what combinations are allowed. For example, can one have a thing which is "table-cell" on the outside and "flex" on the inside, per spec? No, 'table-cell' is currently a keyword and those can't be combined with other keywords at all. [1] However, I'm proposing in [2] that 'table-cell'/'table-caption' should instead be keywords [3], which would allow 'display:table-cell flex' etc. I've written proof-of-concept code to implement that and it was fairly straight-forward now that we support multi-keyword values in general. I didn't see any signs of additional complications regarding anon boxes from this. (To be concrete, removing the inner anon box we currently have for table cells wouldn't become harder, nor easier, by any of these changes.) (I'll add a disclaimer for 'run-in' though. It's not implemented by anyone yet so it's hard to speculate about. I'll also add that I (and others) have doubts about it...) It's worth trying to find out, and in particular to find out whether what we plan to ship is compatible with what they plan to ship. Well, the CSS spec is public and being actively discussed in various github issues / www-style. I would expect them to file a spec issue if they have objections or intend to implement something different. /Mats [1] https://drafts.csswg.org/css-display-3/#the-display-properties [2] https://github.com/w3c/csswg-drafts/issues/3940 [3] https://drafts.csswg.org/css-display-3/#typedef-display-outside ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intend to deprecate: XLink attributes on MathML elements
On 25/08/2019 00:33, Cameron McCormack wrote: > Thank you for cleaning this up, Frédéric. What are the use counter > thresholds you are looking for with these MathML deprecations? A certain > percentage of all pages, or of pages with any MathML? Emilio re-enabled for Mozilla 68 [1] a counter of pages that contained MathML content rendered by Gecko. This is what we plan to use as a reference. We haven't decided about the exact threshold yet though. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1538985 -- Frédéric Wang ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: JS testing functions and compartments in mochitest-plain
On Mon, Aug 26, 2019 at 12:02 AM Henri Sivonen wrote: > If in a plain mochitest I do > var rope = > SpecialPowers.Cu.getJSTestingFunctions().newRope(t.head, t.tail); > var encoded = (new TextEncoder()).encode(rope); > the encode() method doesn't see the rope. Instead, the call to > encode() sees a linear string that was materialized by a copy in a > cross-compartment wrapper. > > Does SpecialPowers always introduce a compartment boundary in a plain > mochitest? For posterity: It does. Components.utils can't be exposed to an unprivileged content compartment directly. > In what type of test does > SpecialPowers.Cu.getJSTestingFunctions().newRope() actually return a > rope within the calling compartment such that passing the rope to a > WebIDL API really makes the rope enter the WebIDL bindings instead of > getting intercepted by a cross-compartment wrapper first? > > Alternatively: What kind of string lengths should I use with normal JS > string concatenation to be sure that I get a rope instead of the right > operand getting copied into an extensible left operand? > > -- > Henri Sivonen > hsivo...@mozilla.com > ___ > 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: Intent to ship: multi-keyword values on the CSS 'display' property
On 8/19/19 3:42 PM, Mats Palmgren wrote: Your point is well taken but it's an independent issue. Sure. I'm just saying that I suspect some of the combinations may be hard to implement using anon boxes, depending on what combinations are allowed. For example, can one have a thing which is "table-cell" on the outside and "flex" on the inside, per spec? I don't know what their plans are. I haven't seen any public announcements one way or another. It's worth trying to find out, and in particular to find out whether what we plan to ship is compatible with what they plan to ship. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: JS testing functions and compartments in mochitest-plain
On Mon, Aug 26, 2019 at 1:37 PM Jan de Mooij wrote: > > On Mon, Aug 26, 2019 at 12:25 PM Henri Sivonen wrote: >> >> Thanks. Since SpecialPowers doesn't exist in xpcshell tests, is there >> another way to reach JS testing functions from there? > > > I think just Cu.getJSTestingFunctions() should work. Thanks. This worked. -- Henri Sivonen hsivo...@mozilla.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Shipped - MOZ_LOG_FILE filenames automatically appended `.moz_log` extension
Bug 1574882 has landed and will ship in Firefox 70. Our XPCOM (MOZ_LOG driven) log files now all have .moz_log extension. The extension cannot be changed. -hb- On 2019-08-19 18:59, Honza Bambas wrote: I'm about to land a patch that will automatically add `mozlog` extension to all log files from all processes produced with MOZ_LOG/_FILE env vars, command line args or via about:networking#logging. It **will not** be possible to remove that extension by setting custom extensions, like `MOZ_LOG=my-log.log`. The resulting filename will be `my-log.log.mozlog`. Please let me know if there is anything we have to fix (test infra, for instance) before doing so. Note that when using `rotate`, the trailing number will still be appended at the end, after the `mozlog` extension. The bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1574882 Thanks. -hb- ___ 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: JS testing functions and compartments in mochitest-plain
On Mon, Aug 26, 2019 at 12:25 PM Henri Sivonen wrote: > Thanks. Since SpecialPowers doesn't exist in xpcshell tests, is there > another way to reach JS testing functions from there? > I think just Cu.getJSTestingFunctions() should work. Jan > > -- > Henri Sivonen > hsivo...@mozilla.com > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: JS testing functions and compartments in mochitest-plain
On Mon, Aug 26, 2019 at 11:27 AM Jan de Mooij wrote: > > On Mon, Aug 26, 2019 at 9:02 AM Henri Sivonen wrote: >> >> In what type of test does >> SpecialPowers.Cu.getJSTestingFunctions().newRope() actually return a >> rope within the calling compartment such that passing the rope to a >> WebIDL API really makes the rope enter the WebIDL bindings instead of >> getting intercepted by a cross-compartment wrapper first? > > > An xpcshell test or mochitest-chrome is probably easiest Thanks. Since SpecialPowers doesn't exist in xpcshell tests, is there another way to reach JS testing functions from there? -- Henri Sivonen hsivo...@mozilla.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
[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 in the last 7 days. Additional details on the team's priorities last week, as well as the plans for the current week are available at: https://tinyurl.com/y3ww45m3. Bugs logged by Desktop Release QA in the last 7 days: Firefox: New Tab Page NEW - https://bugzil.la/1575586 - Links from a Pinned NewTab page open in a new tab instead of the same one Firefox: Session Restore NEW - https://bugzil.la/1575761 - [Ubuntu] Pages not loaded after pave-over update Firefox: Site Identity and Permission Panels * NEW - https://bugzil.la/1575778 - "Show Full Report" is displayed in the privacy panel instead of "Show Report" * RESOLVED FIXED - https://bugzil.la/1575798 - Missing items in the "Blocked" section if deselecting the Cookies checkbox * RESOLVED FIXED - https://bugzil.la/1575812 - [Strict/Custom mode] When Tracking Protection is off the panel is not displayed correctly Firefox: Tracking Protection * RESOLVED FIXED - https://bugzil.la/1575813 - [Custom mode] Cryptominers/Fingerprinters section doesn’t appear in the allowed sections * NEW - https://bugzil.la/1575814 - [Custom Mode] When Cross-Site Tracking Cookies are not blocked, the list for them is empty in the panel * NEW - https://bugzil.la/1576178 - [Windows] The icons inside the Firefox Monitor cards are slightly offset Core: Canvas: WebGL * NEW - https://bugzil.la/1575205 - Crash in [@ raise | _IO_vasprintf] * NEW - https://bugzil.la/1575211 - [Linux] WebGL animations from threejs.org doesn't work properly Core: Document Navigation NEW - https://bugzil.la/1575163 - [Fission] Crash in [@ mozilla::ipc::IPDLParamTraits::Write] Core: Privacy: Anti-Tracking NEW - https://bugzil.la/1575811 - Disabling protections on a site makes first-party social trackers show up in the content blocking log Toolkit: Crash Reporting * NEW - https://bugzil.la/1575187 - Invalid emails are allowed inside the Mozilla Crash Reporter * NEW - https://bugzil.la/1575192 - [win][Crash reporter] Text for email in Allow Mozilla not properly centered Toolkit: Form Autofill NEW - https://bugzil.la/1576186 - Credit Card text field titles are spilling out of their designated area when selected Toolkit: Password Manager * NEW - https://bugzil.la/1575220 - [Windows] Breach notifications are not displayed while High Contrast Mode is applied * NEW - https://bugzil.la/1576175 - [about:logins] Tab key doesn't select anything from the warning panel * NEW - https://bugzil.la/1576177 - [about:logins] There is no hover effect for "Learn more about this breach" hyperlink inside the warning banner. Toolkit: Password Manager: Site Compatibility NEW - https://bugzil.la/1576181 - User can login with incorrect password into Facebook even after Update with incorrect credentials Mozilla Localization: es-ES / Spanish RESOLVED FIXED - https://bugzil.la/1575508 - Quotation marks instead of colon is displayed at the end of Default for all websites string for es-Es locale Mozilla Localization: ar / Arabic RESOLVED FIXED - https://bugzil.la/1575815 - Brand-product name' is displayed in the about:welcome and on supercharge cards for ar locale This is available as a Bugzilla bug list as well: https://tinyurl.com/y4oqpb56. Regards, Mihai Boldan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: JS testing functions and compartments in mochitest-plain
On Mon, Aug 26, 2019 at 9:02 AM Henri Sivonen wrote: > In what type of test does > SpecialPowers.Cu.getJSTestingFunctions().newRope() actually return a > rope within the calling compartment such that passing the rope to a > WebIDL API really makes the rope enter the WebIDL bindings instead of > getting intercepted by a cross-compartment wrapper first? > An xpcshell test or mochitest-chrome is probably easiest.. Or a system Sandbox/evalInSandbox but that becomes more complicated. Strings are copied across zone boundaries so any global in the system zone should work. You can use the isSameCompartment JS testing function to test/assert the following is true in your test: testingFunctions.isSameCompartment(testingFunctions.newRope, this) (same-compartment is a stronger invariant than same-zone but for system compartments it should be fine). > Alternatively: What kind of string lengths should I use with normal JS > string concatenation to be sure that I get a rope instead of the right > operand getting copied into an extensible left operand? > js::ConcatStrings creates a rope if both sides have length > 0 and the result doesn't fit in a JSFatInlineString (limits there are 11 and 23 for Latin1 vs TwoByte chars). The extensible-string optimization applies to rope flattening (we still create a rope first in that case). Hope this helps, Jan > > -- > Henri Sivonen > hsivo...@mozilla.com > ___ > 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
JS testing functions and compartments in mochitest-plain
If in a plain mochitest I do var rope = SpecialPowers.Cu.getJSTestingFunctions().newRope(t.head, t.tail); var encoded = (new TextEncoder()).encode(rope); the encode() method doesn't see the rope. Instead, the call to encode() sees a linear string that was materialized by a copy in a cross-compartment wrapper. Does SpecialPowers always introduce a compartment boundary in a plain mochitest? In what type of test does SpecialPowers.Cu.getJSTestingFunctions().newRope() actually return a rope within the calling compartment such that passing the rope to a WebIDL API really makes the rope enter the WebIDL bindings instead of getting intercepted by a cross-compartment wrapper first? Alternatively: What kind of string lengths should I use with normal JS string concatenation to be sure that I get a rope instead of the right operand getting copied into an extensible left operand? -- Henri Sivonen hsivo...@mozilla.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
