The DOMString type has been removed from XPIDL

[Nicholas Nethercote]

Greetings,

I just landed the patches for bug 1489047, which remove the DOMString type
from XPIDL.

Why? Here are details about how string types in XPIDL and WebIDL are
converted from JS to C++:

- XPIDL AString: `undefined` becomes Void, `null` becomes Void.

- XPIDL DOMString: `undefined` becomes "undefined", `null` becomes Void.

- WebIDL DOMString: `undefined` becomes "undefined", `null` becomes "null"
unless `[TreatNullAs=EmptyString]` is used. Also, `DOMString?` can be used
to get the XPCOM AString behavior.

In other words, XPIDL DOMString was almost-but-not-quite-identical to both
XPIDL AString and WebIDL DOMString. All the actual web-facing DOM stuff is
now defined via WebIDL, so there didn't seem much point in keeping XPIDL
DOMString.

Nick
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Windows launcher process enabled by default on Nightly

[Aaron Klotz]

On 9/28/2018 12:07 PM, Aaron Klotz wrote:


On 9/27/2018 9:47 AM, Ted Mielczarek wrote:
We have `MOZ_DEBUG_CHILD_PROCESS` for e10s content processes[1]. 
Would something similar (or maybe just supporting that?) be useful 
for the browser process as well?

Sure, I have filed bug 1495039.



The patch for this bug is now on autoland and should be merging to 
central shortly. The MOZ_DEBUG_BROWSER_PROCESS and 
MOZ_DEBUG_BROWSER_PAUSE environment variables are analogous to the 
MOZ_DEBUG_CHILD_* equivalents.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Windows launcher process enabled by default on Nightly

[Aaron Klotz]

On 10/1/2018 3:21 AM, Jean-Yves Avenard wrote:
Can we have something to entirely disable that new feature such as 
./mach run --disable-e10s that won't make firefox spawn another process?


affects development/debugging process otherwise, not everyone use 
Visual Studio nor WinDbg for debugging purposes. Having to manually 
attach a process each time is rather unpleasant.


For various reasons we don't want to put escape hatches into any builds 
that we ship.


For local builds, if it would ease developer concerns over this feature, 
we can look into it. I have filed bug 1495628 for that purpose.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Phabricator and updates to commit messages

[Mark Côté]

There’s been a bit of confusion around Phabricator and updates to commit
messages lately (https://bugzilla.mozilla.org/show_bug.cgi?id=1476425).
Arcanist's default workflow is to not update a revision’s Summary field
even if the associated commit message is updated (e.g. by `hg commit
--amend`) and resubmitted via `arc diff`. This has led to people
accidentally checking in the wrong commit message.

We’ve contacted upstream about this issue, and they’ll be looking into it
after the big rewrite of Arcanist that they are currently working on (
https://secure.phabricator.com/T13098). In the meantime, there are other
ways to update the Summary:


   -

   The simplest is to use the web UI to edit the Summary field directly.
   -

   You can also use `arc diff --verbatim` when submitting updates. This
   will update the Summary and some other fields from the commit message. Note
   that you should first run `arc amend` or manually remove the
   #secure-revision tag from the commit message. This tag is used by our
   automation when setting up permissions; if you accidentally set it, you
   will lock down the revision.
   -

   `arc diff --edit` also allows you to update the revision Summary
   directly, but note that the local commit message *won’t* be correspondingly
   updated unless you then run `arc amend`.


For moz-phab, we will be fixing this ourselves by calling Phabricator’s
Conduit API directly. See
https://bugzilla.mozilla.org/show_bug.cgi?id=1494372. We'll be getting to
this after git support is finalized (which is in review right now).

Mark
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Better incremental builds - Tup backend available on Linux

[Chris M.]

On Mon, Oct 1, 2018 at 8:05 AM Randell Jesup  wrote:

> >Tup is a modern build system that enables fast and correct builds. I'm
> >pleased to announce the availability of Tup for building Firefox on Linux.
> >Compared to Make, building with Tup will result in faster incremental
> build
> >times and reduce the need for clobber builds. See the in-tree docs for
> >details [1].
>
> So this seems to be faster for "./mach build" if you have small changes
> to c++ code . However, "./mach build binaries" doesn't work at all.
> (Perhaps with this it's no longer necessary, but if so a message stating
> that would be good).
>

Thanks for trying it out! I've posted a change to  re-direct mach build
"binaries" and "faster" to simply "./mach build" in bug 1493272
. There are more
details in the bug, but simply running "./mach build" in the tup backend
should be as fast and cover cases we'd want "binaries" or "faster" in a
make based backend.


> >cd ~/.mozbuild && mach artifact toolchain --from-build linux64-tup
>
> This doesn't work... no "mach" in my path.  Going to a tree and typing
> './mach artifact toolchain --from-build linux64-tup' works though.
>

We will update the docs to not  assume "mach" is on PATH in bug 1495593



>
> --
> Randell Jesup, Mozilla Corp
> remove "news" for personal email
> ___
> 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

New macOS mach run option: --macos-open

[Haik Aftandilian]

With the fix for bug 1494326[1] (on autoland), when run on macOS, "mach
run" has a new option "--macos-open" to launch the browser using the
open(1) command. Note --macos-open and --debug are mutually exclusive and
mach will exit with an error if both options are used.

Per the open(1) man page, "the open command opens a file (or a directory or
URL), just as if you had double-clicked the file's icon." One big
difference is that the application is spawned directly by the launchd
process instead of via the shell parent process chain.

There is no support for using this with tests, but there is an argument to
be made that our testing would be more representative of real world use if
we started the browser in the same way that users do. That would require
reworking tests to wait for the correct browser process to exit and somehow
collecting stdout/stderr output. That might be something we do in the
future if the option ends up being useful.

One use I've found for this relates to the new macOS 10.14 Mojave device
permission dialogs for the camera/mic. When launched via "mach run", the
dialog is displayed as '"Terminal" would like to access the camera." (I
consider that a macOS limitation and not a Firefox bug.) When launching
with the open command, the dialog is displayed correctly.

Thanks,
Haik

1. https://bugzilla.mozilla.org/show_bug.cgi?id=1494326
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: Phabricator silently drops the content of binary files on Windows

[Mark Côté]

On Saturday, 29 September 2018 21:59:48 UTC-4, Boris Zbarsky  wrote:
> On 9/29/18 11:31 AM, tom...@gmail.com wrote:
> > Our modern roadmap is almost entirely driven by paying customers, and no 
> > customers have expressed interest in this.
> 
> Are we a paying customer?

Yes we are.  I'll file an upstream ticket and update the related bug.

Mark

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Better incremental builds - Tup backend available on Linux

[Randell Jesup]

>Tup is a modern build system that enables fast and correct builds. I'm
>pleased to announce the availability of Tup for building Firefox on Linux.
>Compared to Make, building with Tup will result in faster incremental build
>times and reduce the need for clobber builds. See the in-tree docs for
>details [1].

So this seems to be faster for "./mach build" if you have small changes
to c++ code . However, "./mach build binaries" doesn't work at all.
(Perhaps with this it's no longer necessary, but if so a message stating
that would be good).

>cd ~/.mozbuild && mach artifact toolchain --from-build linux64-tup

This doesn't work... no "mach" in my path.  Going to a tree and typing
'./mach artifact toolchain --from-build linux64-tup' works though.

-- 
Randell Jesup, Mozilla Corp
remove "news" for personal email
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Windows launcher process enabled by default on Nightly

[Jean-Yves Avenard]

Hi


On 27/09/2018 5:19 PM, Aaron Klotz wrote:

Hi everybody,

Yesterday evening bug 1488554 [1] merged to mozilla-central, thus 
enabling the launcher process by default on Windows Nightly builds. 
This change is at the build config level.


Can we have something to entirely disable that new feature such as 
./mach run --disable-e10s that won't make firefox spawn another process?


affects development/debugging process otherwise, not everyone use Visual 
Studio nor WinDbg for debugging purposes. Having to manually attach a 
process each time is rather unpleasant.


Thanks
JY
___
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

[Mihai Boldan]

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/y7rtfmmh

Bugs logged by Desktop Release QA in the last 7 days:

Firefox: Toolbars and Customization
NEW - https://bugzil.la/1493949 - [Ubuntu] White corners are displayed 
after the title bar is deactivated


Firefox: Toolbars and Customization
NEW - https://bugzil.la/1494014 - Incorrect thumbnail is displayed for 
"My Themes"


Firefox: Preferences
NEW - https://bugzil.la/1494353 - The back button is enabled but 
nonfunctional when about:preferences is accessed from other menus


Firefox: Installer
NEW - https://bugzil.la/1494575 - Uninstaller survey - footer not 
contained on zoom


Firefox: Enterprise Policies
NEW - https://bugzil.la/1494598 - Documentation page of about:policies 
should save the users page position when leaving the section


Firefox: Preferences
NEW - https://bugzil.la/1494668 - Restore Defaults is not fully 
functional for all the Content Blocking settings


Firefox: Installer
NEW - https://bugzil.la/1494729 - Uninstaller survey - css - 
radiobuttons centered on list entries instead of at bottom


Firefox: Tracking Protection
NEW - https://bugzil.la/1494744 - The Shield icon is not always 
displayed in the URL Bar, even if blockable resources are detected and 
blocked


Firefox: Installer
RESOLVED - FIXED - https://bugzil.la/1494900 - The uninstall survey is 
not opened when Firefox was the default browser


Firefox: Tabbed Browser
NEW - https://bugzil.la/1494944 - After the tab is resized on the bar 
the close button "x" is displayed only on the focused tab


Firefox: Toolbars and Customization
NEW - https://bugzil.la/1494981 - [Windows 7] "Menu bar" text and items 
color changes when activating "Title bar"


Firefox: Migration
NEW - https://bugzil.la/1495010 - Closing Firefox after migration leads 
to a crash


Firefox: Enterprise Policies
NEW - https://bugzil.la/1495056 - Add smooth scrolling effect to 
about:policies#documentation page


Core: Widget: Gtk
NEW - https://bugzil.la/1493935 - [Ubuntu] The browser jumps across the 
screen when the title bar is deactivated


Core: Widget: Win32
NEW - https://bugzil.la/1494254 - [win] Ebay - dropdown menus still 
displayed after zoom from keyboard


DevTools: General
NEW - https://bugzil.la/1493659 - touchscreen: The "meatball" and 
"chevron" menus break after being double tapped


DevTools: Font Inspector
NEW - https://bugzil.la/1494582 - [RTL]Font editor: Toggle switch for 
"Italic" on RTL builds is spilling out of its designated area


DevTools: Inspector
NEW - https://bugzil.la/1494935 - Can not delete a  node from 
"Delete Node" context menu enabled option, using shadow-root inlining-text


Cloud Services: Server: Remote Settings
NEW - https://bugzil.la/1493985 - Creating a record with no attachment 
hides all the other created records


This is available as a Bugzilla bug list as well: 
https://tinyurl.com/yaa3qqp7


Regards,
Mihai (:mboldan)
Desktop Release QA

Mihai Boldan
QC Engineer
Softvision

The content of this communication is classified as Softvision 
Confidential and Proprietary Information.


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform