Re: Must we rebuild all our rust code constantly?

2019-08-19 Thread Jörg Knobloch

Hi all,

I'm not sure whether Thunderbirds are different, but the issue is that 
(on Windows) xul.dll is constantly relinked although there haven't been 
any changes to C++ or RS files. Log below.


Oh, you can also see some ugly hunspell warnings that have crept in a 
while ago.


Jörg.

$ mach build
 0:02.41 Clobber not needed.
 0:02.42 Adding make options from c:\mozilla-source\comm-central\.mozconfig
    MOZ_MAKE_FLAGS=-j16
MOZ_OBJDIR=c:/mozilla-source/comm-central/obj-x86_64-pc-mingw32
    OBJDIR=c:/mozilla-source/comm-central/obj-x86_64-pc-mingw32
    FOUND_MOZCONFIG=c:/mozilla-source/comm-central/.mozconfig
    export FOUND_MOZCONFIG
 0:02.45 c:\mozilla-build\bin\mozmake.exe -f client.mk 
MOZ_PARALLEL_BUILD=16 -s
 0:02.88 Elapsed: 0.00s; From dist/public: Kept 0 existing; 
Added/updated 0; Removed 0 files and 0 directories.
 0:02.89 Elapsed: 0.00s; From dist/private: Kept 0 existing; 
Added/updated 0; Removed 0 files and 0 directories.
 0:02.91 Elapsed: 0.03s; From dist/xpi-stage: Kept 58 existing; 
Added/updated 0; Removed 0 files and 0 directories.
 0:03.77 Elapsed: 0.88s; From _tests: Kept 0 existing; Added/updated 
1521; Removed 0 files and 0 directories.
 0:03.99 Elapsed: 1.09s; From dist/bin: Kept 0 existing; Added/updated 
2858; Removed 0 files and 0 directories.
 0:04.94 Elapsed: 2.05s; From dist/include: Kept 0 existing; 
Added/updated 6385; Removed 0 files and 0 directories.

 0:04.99 ./buildid.h.stub
 0:05.19 ./source-repo.h.stub
 0:06.02 build/application.ini.stub
 0:06.32 build/application.ini.h.stub
 0:07.03 build/clang-plugin/tests
 0:07.85 toolkit/library/rust/force-cargo-library-build
 0:07.85 js/src/rust/force-cargo-library-build
 0:07.85 js/src/frontend/binast/force-cargo-host-program-build
 0:07.86 testing/geckodriver/force-cargo-program-build
 0:08.05     Blocking waiting for file lock on 
package cache lock
 0:08.05  BlockingBlocking  
waiting for file lock on package cache lockwaiting for file lock on 
package cache lock
 0:09.83     Blocking waiting for file lock on 
package cache lock
 0:11.11     Blocking waiting for file lock on 
package cache lock
 0:12.26     Blocking waiting for file lock on 
package cache lock

 0:13.18 comm/mail/app
 0:13.23 toolkit/library/buildid.cpp.stub
 0:13.45     Blocking waiting for file lock on 
package cache lock
 0:13.45     Blocking waiting for file lock on 
package cache lock
 0:13.48     Blocking waiting for file lock on 
package cache lock
 0:13.48     Blocking waiting for file lock on 
package cache lock
 0:13.48     Blocking waiting for file lock on 
package cache lock
 0:13.50     Blocking waiting for file lock on 
build directory
 0:13.54     Finished dev [optimized + debuginfo] 
target(s) in 5.65s

 0:13.63 toolkit/library
 0:13.78     Finished dev [optimized + debuginfo] 
target(s) in 5.88s
 0:14.17     Finished dev [optimized + debuginfo] 
target(s) in 6.27s
 0:14.26     Finished dev [optimized + debuginfo] 
target(s) in 6.38s

 0:14.42 toolkit/library/build/xul.dll
 0:15.07 comm/mail/app/module.res
 0:15.09 Creating Resource file: module.res
 0:15.12 comm/mail/app/thunderbird.exe
 0:15.26 Embedding manifest from 
../../../../comm/mail/app/thunderbird.exe.manifest
 0:19.93 lld-link: warning: 
..\..\..\extensions\spellcheck\hunspell\glue\Unified_cpp_hunspell_glue0.obj: 
locally defined symbol imported: "public: __cdecl 
Hunspell::~Hunspell(void)" (??1Hunspell@@QEAA@XZ) (defined in 
..\..\..\extensions\spellcheck\hunspell\src\Unified_cpp_hunspell_src0.obj) 
[LNK4217]
 0:19.93 lld-link: warning: 
..\..\..\extensions\spellcheck\hunspell\glue\Unified_cpp_hunspell_glue0.obj: 
locally defined symbol imported: "public: __cdecl 
Hunspell::Hunspell(char const *, char const *, char const *)" 
(??0Hunspell@@QEAA@PEBD00@Z) (defined in 
..\..\..\extensions\spellcheck\hunspell\src\Unified_cpp_hunspell_src0.obj) 
[LNK4217]
 0:19.93 lld-link: warning: 
..\..\..\extensions\spellcheck\hunspell\glue\Unified_cpp_hunspell_glue0.obj: 
locally defined symbol imported: "public: class std::basic_stringstruct std::char_traits, class std::allocator> const & 
__cdecl Hunspell::get_dict_encoding(void) const" 
(?get_dict_encoding@Hunspell@@QEBAAEBV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@XZ) 
(defined in 
..\..\..\extensions\spellcheck\hunspell\src\Unified_cpp_hunspell_src0.obj) 
[LNK4217]
 0:19.93 lld-link: warning: 
..\..\..\extensions\spellcheck\hunspell\glue\Unified_cpp_hunspell_glue0.obj: 
locally defined symbol imported: "public: bool __cdecl 
Hunspell::spell(class std::basic_stringstd::char_traits, class std::allocator> const &, int *, 
class std::basic_string, class 
std::allocator> *)" 

Re: Must we rebuild all our rust code constantly?

2019-08-19 Thread Kris Maglione

On Tue, Aug 20, 2019 at 02:23:06PM +0900, ISHIKAWA,chiaki wrote:

On 2019/08/20 9:11, Dave Townsend wrote:

Thanks to a tip I've tracked this down. This seems to only be the case when
I have sccache enabled. Disabling it gives me nice quick incremental builds
again. Of course that isn't an ideal solution but it will do for now.

On Mon, Aug 19, 2019 at 1:55 PM Dave Townsend  wrote:


For a couple of weeks now I've seen that any attempt to build Firefox,
even incremental builds seem to rebuild an awful lot of rust code. I found
this in the source which seems to suggest why:
https://searchfox.org/mozilla-central/source/config/makefiles/rust.mk#238.
But, this means that now an incremental build with a couple of code change
that have no impact on rust is taking upwards of 4 minutes to complete in
comparison to around 40 seconds, and the log file is full of cargo output.
I've heard similar comments from other developers.

This is a pretty big increase in the time to compile and test and is
really slowing down my work. Is there any way we can avoid this?






I am using linux for local development and noticed something similar.

So I should disable sccache (!?).


For what it's worth, Rust is now configured to use incremental 
compilation, which has its own cache which isn't cleared after 
clobber, so sccache isn't actually needed anymore. Ordinary 
ccache should be sufficient.

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


Re: Must we rebuild all our rust code constantly?

2019-08-19 Thread ISHIKAWA,chiaki

On 2019/08/20 9:11, Dave Townsend wrote:

Thanks to a tip I've tracked this down. This seems to only be the case when
I have sccache enabled. Disabling it gives me nice quick incremental builds
again. Of course that isn't an ideal solution but it will do for now.

On Mon, Aug 19, 2019 at 1:55 PM Dave Townsend  wrote:


For a couple of weeks now I've seen that any attempt to build Firefox,
even incremental builds seem to rebuild an awful lot of rust code. I found
this in the source which seems to suggest why:
https://searchfox.org/mozilla-central/source/config/makefiles/rust.mk#238.
But, this means that now an incremental build with a couple of code change
that have no impact on rust is taking upwards of 4 minutes to complete in
comparison to around 40 seconds, and the log file is full of cargo output.
I've heard similar comments from other developers.

This is a pretty big increase in the time to compile and test and is
really slowing down my work. Is there any way we can avoid this?






I am using linux for local development and noticed something similar.

So I should disable sccache (!?).



___
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: Must we rebuild all our rust code constantly?

2019-08-19 Thread Adam Gashlin
Is this https://bugzilla.mozilla.org/show_bug.cgi?id=1427313 ?

On Mon, Aug 19, 2019 at 5:27 PM Kris Maglione  wrote:

> This is apparently a known bug that no-one seems to be able to
> track down the cause of. It suddenly started happening to me one
> night for every build, even if I changed nothing. Then, just as
> suddenly, stopped happening after a couple of hours.
>
> On Mon, Aug 19, 2019 at 05:11:19PM -0700, Dave Townsend wrote:
> >Thanks to a tip I've tracked this down. This seems to only be the case
> when
> >I have sccache enabled. Disabling it gives me nice quick incremental
> builds
> >again. Of course that isn't an ideal solution but it will do for now.
> >
> >On Mon, Aug 19, 2019 at 1:55 PM Dave Townsend 
> wrote:
> >
> >> For a couple of weeks now I've seen that any attempt to build Firefox,
> >> even incremental builds seem to rebuild an awful lot of rust code. I
> found
> >> this in the source which seems to suggest why:
> >>
> https://searchfox.org/mozilla-central/source/config/makefiles/rust.mk#238.
> >> But, this means that now an incremental build with a couple of code
> change
> >> that have no impact on rust is taking upwards of 4 minutes to complete
> in
> >> comparison to around 40 seconds, and the log file is full of cargo
> output.
> >> I've heard similar comments from other developers.
> >>
> >> This is a pretty big increase in the time to compile and test and is
> >> really slowing down my work. Is there any way we can avoid this?
> ___
> 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: Must we rebuild all our rust code constantly?

2019-08-19 Thread Kris Maglione
This is apparently a known bug that no-one seems to be able to 
track down the cause of. It suddenly started happening to me one 
night for every build, even if I changed nothing. Then, just as 
suddenly, stopped happening after a couple of hours.


On Mon, Aug 19, 2019 at 05:11:19PM -0700, Dave Townsend wrote:

Thanks to a tip I've tracked this down. This seems to only be the case when
I have sccache enabled. Disabling it gives me nice quick incremental builds
again. Of course that isn't an ideal solution but it will do for now.

On Mon, Aug 19, 2019 at 1:55 PM Dave Townsend  wrote:


For a couple of weeks now I've seen that any attempt to build Firefox,
even incremental builds seem to rebuild an awful lot of rust code. I found
this in the source which seems to suggest why:
https://searchfox.org/mozilla-central/source/config/makefiles/rust.mk#238.
But, this means that now an incremental build with a couple of code change
that have no impact on rust is taking upwards of 4 minutes to complete in
comparison to around 40 seconds, and the log file is full of cargo output.
I've heard similar comments from other developers.

This is a pretty big increase in the time to compile and test and is
really slowing down my work. Is there any way we can avoid this?

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


Re: Must we rebuild all our rust code constantly?

2019-08-19 Thread Dave Townsend
Thanks to a tip I've tracked this down. This seems to only be the case when
I have sccache enabled. Disabling it gives me nice quick incremental builds
again. Of course that isn't an ideal solution but it will do for now.

On Mon, Aug 19, 2019 at 1:55 PM Dave Townsend  wrote:

> For a couple of weeks now I've seen that any attempt to build Firefox,
> even incremental builds seem to rebuild an awful lot of rust code. I found
> this in the source which seems to suggest why:
> https://searchfox.org/mozilla-central/source/config/makefiles/rust.mk#238.
> But, this means that now an incremental build with a couple of code change
> that have no impact on rust is taking upwards of 4 minutes to complete in
> comparison to around 40 seconds, and the log file is full of cargo output.
> I've heard similar comments from other developers.
>
> This is a pretty big increase in the time to compile and test and is
> really slowing down my work. Is there any way we can avoid this?
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


PSA: Removing display:-moz-inline-grid and -moz-inline-stack

2019-08-19 Thread Mats Palmgren

In bug 1574994, I'm removing the display:-moz-inline-grid/stack values.
(They are inline-level versions of display:-moz-grid/stack XUL boxes
which we continue to support, for now).

These values are not exposed to web-content and there are no internal
uses in mozilla-central nor comm-central.


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


Must we rebuild all our rust code constantly?

2019-08-19 Thread Dave Townsend
For a couple of weeks now I've seen that any attempt to build Firefox, even
incremental builds seem to rebuild an awful lot of rust code. I found this
in the source which seems to suggest why:
https://searchfox.org/mozilla-central/source/config/makefiles/rust.mk#238.
But, this means that now an incremental build with a couple of code change
that have no impact on rust is taking upwards of 4 minutes to complete in
comparison to around 40 seconds, and the log file is full of cargo output.
I've heard similar comments from other developers.

This is a pretty big increase in the time to compile and test and is really
slowing down my work. Is there any way we can avoid this?
___
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

2019-08-19 Thread Mats Palmgren

On 8/14/19 6:52 PM, Boris Zbarsky wrote:

On 8/14/19 12:37 PM, Mats Palmgren wrote:

This first patch set adds support for the new syntax
only, but no new box types (I'll add those separately in a bit).


In general, it seems like we should think about how to integrate this 
stuff into layout in a better way than anonymous boxes everywhere.  In 
particular, we may want to consider changing nsIFrame such that we have it 
point to a "how I look to my parent" class and a "how I manage my kids or 
paint myself" class and be able to mix and match those.



I agree, but splitting up the 'display' property into three separate
keywords doesn't imply we'll implement them using anonymous boxes in
more cases than if it's just one keyword.  Your point is well taken but
it's an independent issue.

I'm guessing you're thinking of the implementation of 'block ruby',
which indeed does introduce a new anonymous box (it's a block box with
anonymous ruby box inside it).
This is mandated by the Ruby spec though:
"If an element has an inner display type of ruby and an outer display type 
other than inline, then it generates two boxes: a principal box of the 
required outer display type type, and an inline-level ruby container. All 
properties specified on the element apply to the principal box (and if 
inheritable, inherit to the ruby container box)."

https://drafts.csswg.org/css-ruby-1/#block-ruby

(It makes sense to me to use two boxes in this case.  I'm happy to
continue discuss that off-list I you want.)

(There are no anonymous boxes associated with any of the list-item values.)



Other browsers: Other UAs don't support this yet, AFAIK.


Do they plan to?



I don't know what their plans are.  I haven't seen any public
announcements one way or another.


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


MOZ_LOG_FILE filename intended to be automatically and irrevocably appended `.mozlog` extension

2019-08-19 Thread Honza Bambas
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


Re: Fission Newsletter #2

2019-08-19 Thread Henrik Skupin
Nika Layzell wrote on 09.08.19 19:33:

>Wait for document loads to complete before trying to run code inside the
>target window, as a process switch may occur after the frame or browser is
>created. For frames in content, this usually means waiting for the load
>event.

While working to get the new screenshot API into Marionette I noticed a
couple of problems, which were all related to page load events inside
OOP iframes.

The underlying reason is that the top-browsing context doesn't wait yet,
until all the documents of OOP frames have been finished loading. See
bug 1559841.

Please be aware of that if you run into intermittent failures.
___
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

2019-08-19 Thread Mihai Boldan

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/y28kjp78.

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

Firefox: Bookmarks & History
NEW - https://bugzil.la/1573494 - Focus does not remain on a bookmark 
that's moved inside bookmark manager (library or sidebar)


Firefox: Search
* NEW - https://bugzil.la/1574461 - [Ubuntu] Search suggestions are not 
shown if re-enabled the Search bar after it was removed by using the 
“Remove from Toolbar “ option
* NEW - https://bugzil.la/1574460 - [Ubuntu] Search drop-down panel is 
not instantly dismissed if removing the Search bar through “Remove from 
Toolbar “ option


Firefox: Theme
RESOLVED FIXED - https://bugzil.la/1573161 - Bookmark separators are 
disrupted inside Library


Core: Canvas: WebGL
NEW - https://bugzil.la/1573514 - [Facebook] Gardenscapes game doesn't work

Core: Layout: Form Controls
NEW - https://bugzil.la/1573819 - [Linkedin] First typed character 
inside the Comment section exceeds the textarea boundaries


Core: User events and focus handling
NEW - https://bugzil.la/1573117 - Facebook selection triggered after 
closing your story while Chats pane is toggled on


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


Regards,
Mihai Boldan














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