Re: Intent to ship: CSSOM-View Scroll-Behavior CSS Property and CSSOM-View DOM Extensions for Smooth Scrolling

2014-10-27 Thread Jonas Sicking 
Last we talked about this, I thought that we concluded that smooth
scrolling wasn't so much a property of the element, but rather a
property of the callsite.

See my two emails to the intent to implement thread.

Did this change?

/ Jonas

On Mon, Oct 27, 2014 at 1:31 PM, Kip Gilbert  wrote:
> As of October 28, 2014 I intend to turn on by default CSSOM-View
> Scroll-Behavior CSS Property and CSSOM-View DOM Extensions related to
> smooth scrolling.  They have been developed behind the
> layout.css.scroll-behavior.enabled and
> layout.css.scroll-behavior.property-enabled preferences.  Firefox is
> the first UA to ship this feature.  Chrome has an implementation,
> disabled by default.
>
> Platform coverage: This will be enabled on all platforms except for
> Fennec.  (Fennec will be enabled once the C++ based APZC
> implementation ships for Fennec)
>
> This feature was previously discussed in this "intent to implement"
> thread:
> https://groups.google.com/d/msg/mozilla.dev.platform/mrsNyaLj3Ig/jooFD8rePzAJ
>
> Further discussions occurred on www-style:
>
> http://lists.w3.org/Archives/Public/www-style/2014May/0255.html
> http://lists.w3.org/Archives/Public/www-style/2013May/0361.html
> http://lists.w3.org/Archives/Public/www-style/2014Oct/0014.html
>
> Bugs to turn on by default:
>
> Bug 1087562 - Enable CSSOM-View scroll behavior CSS property by
> default (Except for Fennec)
>
> Bug 1087559 - Enable CSSOM-View scroll behavior DOM method extensions
> by default (Except for Fennec)
>
> Since the original intent to implement email, the specification has
> evolved.  The CSSOM-View DOM Extensions have been changed to accept
> dictionaries for options and the 'instant' value for scroll-behavior
> has been changed to 'auto'.
>
> Bug: 964097 - [meta] Implement CSSOM-View smooth scrolling spec
>
> Link to standard:
>
> http://dev.w3.org/csswg/cssom-view/#smooth-scrolling:-the-%27scroll-behavior%27-property
> http://dev.w3.org/csswg/cssom-view/#extensions-to-the-window-interface
> http://dev.w3.org/csswg/cssom-view/#extensions-to-the-element-interface
>
> ___
> 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: Removing unused Perl scripts from the tree

2014-10-27 Thread Nicholas Nethercote 
On Mon, Oct 27, 2014 at 4:49 PM, Karl Tomlinson  wrote:
>
>> ./layout/mathml/updateOperatorDictionary.pl
>> - appears to be in fairly recent use
>
> This was used to generate an in-tree file from an external spec.
> It is reasonably likely that there will be future changes to the
> spec, in which case the script will again be useful.

Thank you for the info. Do you know which file, and what the specific
command to run it is? I ask because as well as removing the unused
scripts, I'm trying to improve the comments at the top of some of the
still-useful scripts to make things easier for future readers.

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

MemShrink Meeting - Tuesday, 28 Oct 2014 at 4:00pm PDT

2014-10-27 Thread Jet Villegas 
The next Memshrink meeting is is brought to you by e10s now reporting 
performance timing in the content process:
https://bugzilla.mozilla.org/show_bug.cgi?id=1079705

The wiki page for this meeting is at:
   https://wiki.mozilla.org/Performance/MemShrink

Agenda:
* Prioritize unprioritized MemShrink bugs.
* Discuss how we measure progress.
* Discuss approaches to getting more data.

Meeting details:

* Tue, 28 October, 4:00 PM PDT
* http://arewemeetingyet.com/Los%20Angeles/2014-10-28/16:00/MemShrink%20Meeting
* Vidyo: Memshrink
* Dial-in Info:
   - In office or soft phone: extension 92
   - US/INTL: 650-903-0800 or 650-215-1282 then extension 92
   - Toll-free: 800-707-2533 then password 369
   - Conference num 98802
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Removing unused Perl scripts from the tree

2014-10-27 Thread Karl Tomlinson 
Nicholas Nethercote writes:

> UNSURE
> --

> ./layout/mathml/updateOperatorDictionary.pl
> - appears to be in fairly recent use

This was used to generate an in-tree file from an external spec.
It is reasonably likely that there will be future changes to the
spec, in which case the script will again be useful.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Removing unused Perl scripts from the tree

2014-10-27 Thread Nicholas Nethercote 
A clarification: I'm not planning to do anything with the scripts in
the "THIRD-PARTY" section, unless somebody tells me "foo.pl is not
third-party and can be safely removed".

Nick

On Mon, Oct 27, 2014 at 3:18 PM, Nicholas Nethercote
 wrote:
> Hi,
>
> In https://bugzilla.mozilla.org/show_bug.cgi?id=1089446 I'm removing
> some old, unused Perl scripts from the tree. I'm giving notice here
> just in case any of the scripts I'm planning to remove are still being
> used, and also to find out if more scripts can be removed.
>
> My working list and notes are below. Everything in the "REMOVING"
> section is on track to be removed. Assistance on the "UNSURE" section
> would be helpful.
>
> Thank you.
>
> Nick
>
>
> REMOVING
> 
> ./config/make-atom-strings.pl
> - patch to remove is r=bz
>
> ./gfx/tests/process-textruns.pl
> - patch to remove is r=roc
>
> ./build/unix/uniq.pl
> - patch to replace it with uniq.py is r=gps
>
> ./config/module2dir.pl
> - not touched meaningfully since 2003; lots of touches before that
> - glandium says it has been broken since 2008, and hence unused
> - patch to remove it is r?glandium
>
> ./netwerk/test/neckoTiming.pl
> - landed in 2001, hasn't been touched since
> - patch to remove is r?mcmanus
>
> ./xpcom/tools/analyze-xpcom-log.pl
> - unchanged since 2001, unmentioned in the repo
> - patch to remove is r?froydnj
>
> ./build/unix/abs2rel.pl
> - landed in April 2002, no non-trivial changes since then
> - no other references in the repo
> - patch to remove is r?mshal (in bug 1089832)
>
> UNSURE
> --
> ./layout/tools/reftest/clean-reftest-output.pl
> ./layout/tools/reftest/reftest-to-html.pl
> - mentioned in layout/tools/reftest/README.txt
> - dbaron says probably not useful
>
> ./dom/xslt/tests/buster/helper/generate-rdf.pl
> - no other references in the repo
> - bz thinks it's unused; peterv might know better
>
> ./layout/mathml/updateOperatorDictionary.pl
> - appears to be in fairly recent use
>
> ./layout/reftests/fonts/generate-bitpattern-font.pl
> - mentioned by bidiMirroring.svg
>
> ./xpcom/reflect/xptcall/genstubs.pl
> - has moderately recent use
> - mentioned in porting.html
>
> ./gfx/thebes/genLanguageTagList.pl
> - seems like it might still be useful
> - used to generate gfxLanguageTagList.{cpp,h}
>
> ./security/manager/ssl/tests/unit/test_certificate_usages/generate.pl
> - mentioned in comments in
> security/manager/ssl/tests/unit/test_certificate_usages.js
>
> DEFINITELY USEFUL
> -
> ./toolkit/locales/compare-locales.pl
> - Callek says it's still used for some SeaMonkey extensions
>
> ./tools/memory/bloattable.pl
> - still works with bloat logs from XPCOM_MEM_BLOAT_LOG
>
> ./tools/rb/find-comptr-leakers.pl
> ./tools/rb/find-leakers.pl
> ./tools/rb/filter-log.pl
> ./tools/rb/make-tree.pl
> ./tools/rb/bloatdiff.pl
> - all(?) still work with refcnt tracing
>
> ./tools/trace-malloc/blame.pl
> ./tools/trace-malloc/diffbloatdump.pl
> ./tools/trace-malloc/merge.pl
> ./tools/trace-malloc/histogram.pl
> ./tools/trace-malloc/leak-soup.pl
> ./tools/trace-malloc/uncategorized.pl
> - all(?) still work with trace-malloc logs
>
> ./tools/update-packaging/unwrap_full_update.pl
> - used in tools/update-packaging/Makefile.in
>
> ./tools/leak-gauge/leak-gauge.pl
> - still works
>
> ./config/milestone.pl
> - used in configure.in and other places
>
> ./config/version_win.pl
> - used in config/version.mk
>
> ./docshell/test/chrome/gen_template.pl
> ./testing/mochitest/gen_template.pl
> - useful when creating new tests
>
> ./testing/web-platform/tests/tools/pywebsocket/src/test/testdata/hello.pl
> - used in a test
>
> ./build/win32/dumpenv4python.pl
> - used in build/autoconf/hooks.m4
>
> THIRD-PARTY
> ---
> ./gfx/cairo/libpixman/src/make-combine.pl
>
> ./intl/lwbrk/tools/anzx4051.pl
> ./intl/uconv/tools/genimpldefine.pl
> ./intl/uconv/tools/jamap.pl
> ./intl/uconv/tools/parse-mozilla-encoding-table.pl
> ./intl/uconv/tools/gen-big5hkscs-2001-mozilla.pl
> ./intl/uconv/tools/cp936tocdx.pl
> ./intl/uconv/tools/jis0212tojdx.pl
> ./intl/uconv/tools/unihan2cns.pl
> ./intl/uconv/tools/mkjpconv.pl
> ./intl/uconv/tools/adobe.pl
> ./intl/uconv/tools/gengb18030tables.pl
> ./intl/uconv/tests/stressgb.pl
> ./intl/chardet/tools/charfreqtostat.pl
> ./intl/chardet/tools/geniso2022cn.pl
> ./intl/chardet/tools/genhz.pl
> ./intl/chardet/tools/genbig5.pl
> ./intl/chardet/tools/charfreq.pl
> ./intl/chardet/tools/gengb18030.pl
> ./intl/chardet/tools/geniso2022jp.pl
> ./intl/chardet/tools/geneuctw.pl
> ./intl/chardet/tools/gensjis.pl
> ./intl/chardet/tools/geneuckr.pl
> ./intl/chardet/tools/geneucjp.pl
> ./intl/chardet/tools/gencyrillic.pl
> ./intl/chardet/tools/gencp1252.pl
> ./intl/chardet/tools/gengb2312.pl
> ./intl/chardet/tools/genutf8.pl
> ./intl/chardet/tools/geniso2022kr.pl
> ./intl/unicharutil/tools/genSpecialCasingData.pl
> ./intl/unicharutil/tools/gentransliterate.pl
> ./intl/unicharutil/tools/genUnicodePropertyData.pl
> ./intl/unicharutil/tests/genNormalizationData.pl

Re: Removing unused Perl scripts from the tree

2014-10-27 Thread Ralph Giles 
On 2014-10-27 3:18 PM, Nicholas Nethercote wrote:

> ./media/libopus/celt/arm/arm2gnu.pl
> ./media/libvpx/build/make/ads2gas.pl
> ./media/libtheora/lib/arm/arm2gnu.pl

These come from upstream, and are used to convert syntax of assembler
source files so they can work with various toolchains. Upstream is
unlikely to accept python conversions (perl is more widely deployed) so
I don't think it makes sense to remove or replace these.

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

Re: Removing unused Perl scripts from the tree

2014-10-27 Thread L. David Baron 
On Monday 2014-10-27 15:18 -0700, Nicholas Nethercote wrote:
> ./layout/reftests/fonts/generate-bitpattern-font.pl
> - mentioned by bidiMirroring.svg

I believe this is code that was used to generate a file checked in
to the tree (BitPattern.woff, in the same directory, although there
was presumably another conversion step after the script).  It's
generally good practice to have the source code that generated a
generated file checked in along with it, when generated files need
to be checked in.  (It may even be required by some software
licenses.)

-David

-- 
𝄞   L. David Baron http://dbaron.org/   𝄂
𝄢   Mozilla  https://www.mozilla.org/   𝄂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


signature.asc
Description: Digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Removing unused Perl scripts from the tree

2014-10-27 Thread David Keeler 
Thanks for doing this!

On 10/27/2014 03:18 PM, Nicholas Nethercote wrote:

> ./security/manager/ssl/tests/unit/test_certificate_usages/generate.pl
> - mentioned in comments in
> security/manager/ssl/tests/unit/test_certificate_usages.js

We probably still need this until bug 969985[0] is fixed (in which we
want to convert it to a python script).

[0] https://bugzilla.mozilla.org/show_bug.cgi?id=969985
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Removing unused Perl scripts from the tree

2014-10-27 Thread Nicholas Nethercote 
Hi,

In https://bugzilla.mozilla.org/show_bug.cgi?id=1089446 I'm removing
some old, unused Perl scripts from the tree. I'm giving notice here
just in case any of the scripts I'm planning to remove are still being
used, and also to find out if more scripts can be removed.

My working list and notes are below. Everything in the "REMOVING"
section is on track to be removed. Assistance on the "UNSURE" section
would be helpful.

Thank you.

Nick


REMOVING

./config/make-atom-strings.pl
- patch to remove is r=bz

./gfx/tests/process-textruns.pl
- patch to remove is r=roc

./build/unix/uniq.pl
- patch to replace it with uniq.py is r=gps

./config/module2dir.pl
- not touched meaningfully since 2003; lots of touches before that
- glandium says it has been broken since 2008, and hence unused
- patch to remove it is r?glandium

./netwerk/test/neckoTiming.pl
- landed in 2001, hasn't been touched since
- patch to remove is r?mcmanus

./xpcom/tools/analyze-xpcom-log.pl
- unchanged since 2001, unmentioned in the repo
- patch to remove is r?froydnj

./build/unix/abs2rel.pl
- landed in April 2002, no non-trivial changes since then
- no other references in the repo
- patch to remove is r?mshal (in bug 1089832)

UNSURE
--
./layout/tools/reftest/clean-reftest-output.pl
./layout/tools/reftest/reftest-to-html.pl
- mentioned in layout/tools/reftest/README.txt
- dbaron says probably not useful

./dom/xslt/tests/buster/helper/generate-rdf.pl
- no other references in the repo
- bz thinks it's unused; peterv might know better

./layout/mathml/updateOperatorDictionary.pl
- appears to be in fairly recent use

./layout/reftests/fonts/generate-bitpattern-font.pl
- mentioned by bidiMirroring.svg

./xpcom/reflect/xptcall/genstubs.pl
- has moderately recent use
- mentioned in porting.html

./gfx/thebes/genLanguageTagList.pl
- seems like it might still be useful
- used to generate gfxLanguageTagList.{cpp,h}

./security/manager/ssl/tests/unit/test_certificate_usages/generate.pl
- mentioned in comments in
security/manager/ssl/tests/unit/test_certificate_usages.js

DEFINITELY USEFUL
-
./toolkit/locales/compare-locales.pl
- Callek says it's still used for some SeaMonkey extensions

./tools/memory/bloattable.pl
- still works with bloat logs from XPCOM_MEM_BLOAT_LOG

./tools/rb/find-comptr-leakers.pl
./tools/rb/find-leakers.pl
./tools/rb/filter-log.pl
./tools/rb/make-tree.pl
./tools/rb/bloatdiff.pl
- all(?) still work with refcnt tracing

./tools/trace-malloc/blame.pl
./tools/trace-malloc/diffbloatdump.pl
./tools/trace-malloc/merge.pl
./tools/trace-malloc/histogram.pl
./tools/trace-malloc/leak-soup.pl
./tools/trace-malloc/uncategorized.pl
- all(?) still work with trace-malloc logs

./tools/update-packaging/unwrap_full_update.pl
- used in tools/update-packaging/Makefile.in

./tools/leak-gauge/leak-gauge.pl
- still works

./config/milestone.pl
- used in configure.in and other places

./config/version_win.pl
- used in config/version.mk

./docshell/test/chrome/gen_template.pl
./testing/mochitest/gen_template.pl
- useful when creating new tests

./testing/web-platform/tests/tools/pywebsocket/src/test/testdata/hello.pl
- used in a test

./build/win32/dumpenv4python.pl
- used in build/autoconf/hooks.m4

THIRD-PARTY
---
./gfx/cairo/libpixman/src/make-combine.pl

./intl/lwbrk/tools/anzx4051.pl
./intl/uconv/tools/genimpldefine.pl
./intl/uconv/tools/jamap.pl
./intl/uconv/tools/parse-mozilla-encoding-table.pl
./intl/uconv/tools/gen-big5hkscs-2001-mozilla.pl
./intl/uconv/tools/cp936tocdx.pl
./intl/uconv/tools/jis0212tojdx.pl
./intl/uconv/tools/unihan2cns.pl
./intl/uconv/tools/mkjpconv.pl
./intl/uconv/tools/adobe.pl
./intl/uconv/tools/gengb18030tables.pl
./intl/uconv/tests/stressgb.pl
./intl/chardet/tools/charfreqtostat.pl
./intl/chardet/tools/geniso2022cn.pl
./intl/chardet/tools/genhz.pl
./intl/chardet/tools/genbig5.pl
./intl/chardet/tools/charfreq.pl
./intl/chardet/tools/gengb18030.pl
./intl/chardet/tools/geniso2022jp.pl
./intl/chardet/tools/geneuctw.pl
./intl/chardet/tools/gensjis.pl
./intl/chardet/tools/geneuckr.pl
./intl/chardet/tools/geneucjp.pl
./intl/chardet/tools/gencyrillic.pl
./intl/chardet/tools/gencp1252.pl
./intl/chardet/tools/gengb2312.pl
./intl/chardet/tools/genutf8.pl
./intl/chardet/tools/geniso2022kr.pl
./intl/unicharutil/tools/genSpecialCasingData.pl
./intl/unicharutil/tools/gentransliterate.pl
./intl/unicharutil/tools/genUnicodePropertyData.pl
./intl/unicharutil/tests/genNormalizationData.pl
./intl/icu/source/common/rbbicst.pl
./intl/icu/source/tools/genren/genren.pl
./intl/icu/source/tools/memcheck/ICUMemCheck.pl
./intl/icu/source/tools/gensprep/filterRFC3454.pl
./intl/icu/source/i18n/regexcst.pl

./nsprpub/pr/src/misc/compile-et.pl
./nsprpub/pr/tests/runtests.pl
./nsprpub/config/make-system-wrappers.pl
./nsprpub/config/nfspwd.pl
./nsprpub/admin/explode.pl

./media/libopus/celt/arm/arm2gnu.pl
./media/libvpx/build/make/ads2gas.pl
./media/libtheora/lib/arm/arm2gnu.pl

./extensions/spellcheck/locales/en-US

Re: Intent to ship: CSSOM-View Scroll-Behavior CSS Property and CSSOM-View DOM Extensions for Smooth Scrolling

2014-10-27 Thread Jet Villegas 
\o/

Cross-posting to b2g-internal as these are the features the Gaia team will use 
for the scrolling effects requested for Firefox OS.

--Jet

- Original Message -
From: "Kip Gilbert" 
To: dev-platform@lists.mozilla.org
Sent: Monday, October 27, 2014 1:31:43 PM
Subject: Intent to ship: CSSOM-View Scroll-Behavior CSS Property and CSSOM-View 
DOM Extensions for Smooth Scrolling

As of October 28, 2014 I intend to turn on by default CSSOM-View
Scroll-Behavior CSS Property and CSSOM-View DOM Extensions related to
smooth scrolling.  They have been developed behind the
layout.css.scroll-behavior.enabled and
layout.css.scroll-behavior.property-enabled preferences.  Firefox is
the first UA to ship this feature.  Chrome has an implementation,
disabled by default.

Platform coverage: This will be enabled on all platforms except for
Fennec.  (Fennec will be enabled once the C++ based APZC
implementation ships for Fennec)

This feature was previously discussed in this "intent to implement"
thread:
https://groups.google.com/d/msg/mozilla.dev.platform/mrsNyaLj3Ig/jooFD8rePzAJ

Further discussions occurred on www-style:

http://lists.w3.org/Archives/Public/www-style/2014May/0255.html
http://lists.w3.org/Archives/Public/www-style/2013May/0361.html
http://lists.w3.org/Archives/Public/www-style/2014Oct/0014.html

Bugs to turn on by default:

Bug 1087562 - Enable CSSOM-View scroll behavior CSS property by
default (Except for Fennec)

Bug 1087559 - Enable CSSOM-View scroll behavior DOM method extensions
by default (Except for Fennec)

Since the original intent to implement email, the specification has
evolved.  The CSSOM-View DOM Extensions have been changed to accept
dictionaries for options and the 'instant' value for scroll-behavior
has been changed to 'auto'.

Bug: 964097 - [meta] Implement CSSOM-View smooth scrolling spec

Link to standard:

http://dev.w3.org/csswg/cssom-view/#smooth-scrolling:-the-%27scroll-behavior%27-property
http://dev.w3.org/csswg/cssom-view/#extensions-to-the-window-interface
http://dev.w3.org/csswg/cssom-view/#extensions-to-the-element-interface

___
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

Intent to ship: CSSOM-View Scroll-Behavior CSS Property and CSSOM-View DOM Extensions for Smooth Scrolling

2014-10-27 Thread Kip Gilbert 
As of October 28, 2014 I intend to turn on by default CSSOM-View
Scroll-Behavior CSS Property and CSSOM-View DOM Extensions related to
smooth scrolling.  They have been developed behind the
layout.css.scroll-behavior.enabled and
layout.css.scroll-behavior.property-enabled preferences.  Firefox is
the first UA to ship this feature.  Chrome has an implementation,
disabled by default.

Platform coverage: This will be enabled on all platforms except for
Fennec.  (Fennec will be enabled once the C++ based APZC
implementation ships for Fennec)

This feature was previously discussed in this "intent to implement"
thread:
https://groups.google.com/d/msg/mozilla.dev.platform/mrsNyaLj3Ig/jooFD8rePzAJ

Further discussions occurred on www-style:

http://lists.w3.org/Archives/Public/www-style/2014May/0255.html
http://lists.w3.org/Archives/Public/www-style/2013May/0361.html
http://lists.w3.org/Archives/Public/www-style/2014Oct/0014.html

Bugs to turn on by default:

Bug 1087562 - Enable CSSOM-View scroll behavior CSS property by
default (Except for Fennec)

Bug 1087559 - Enable CSSOM-View scroll behavior DOM method extensions
by default (Except for Fennec)

Since the original intent to implement email, the specification has
evolved.  The CSSOM-View DOM Extensions have been changed to accept
dictionaries for options and the 'instant' value for scroll-behavior
has been changed to 'auto'.

Bug: 964097 - [meta] Implement CSSOM-View smooth scrolling spec

Link to standard:

http://dev.w3.org/csswg/cssom-view/#smooth-scrolling:-the-%27scroll-behavior%27-property
http://dev.w3.org/csswg/cssom-view/#extensions-to-the-window-interface
http://dev.w3.org/csswg/cssom-view/#extensions-to-the-element-interface

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

Test Informant Report - Week of Oct 19th

2014-10-27 Thread Andrew Halberstadt 

Test Informant report for 2014-10-26.

State of test manifests at revision 8230834302c9.
Using revision 33c0181c4a25 as a baseline for comparisons.
Showing tests enabled or disabled between 2014-10-18 and 2014-10-26.

86% of tests across all suites and configurations are enabled.

Summary
---
marionette- ↑0↓4   - 92%
mochitest-a11y- ↑0↓0   - 99%
mochitest-browser-chrome  - ↑144↓64 - 95%
mochitest-browser-chrome-e10s - ↑386↓2 - 37%
mochitest-chrome  - ↑2286↓2270 - 97%
mochitest-plain   - ↑13652↓13390 - 86%
mochitest-plain-e10s  - ↑4506↓4302 - 79%
xpcshell  - ↑211↓82 - 92%


Full Report
---
http://brasstacks.mozilla.com/testreports/weekly/2014-10-26.informant-report.html


Notes
-
* Large number of tests enabled/disabled due to directory refactor 
moving several content/* directories under dom/

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

Re: MSE WebM/VP9 enabled on nightly

2014-10-27 Thread ishikawa 
On 2014年10月27日 18:30, Bobby Holley wrote:
> This issue is off-topic for this thread. Please file a bug and CC a build
> peer.
> 

Sorry, will do.

TIA

> On Mon, Oct 27, 2014 at 10:06 AM, ishikawa  wrote:
> 
>> > Sorry for top-posting:
>> >
>> > The error mentioned about the missing files was again observed on a PC
>> > which has C-C tree refreshed this morning.
>> >
>> > The error for one of the file is as follows:
>> >
>> > make[4]: *** No rule to make target
>> >
>> > '/new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mozilla/media/libvpx/vp9/decoder/vp9_thread.c',
>> > needed by 'vp9_thread.o'.  Stop.
>> > make[4]: *** Waiting for unfinished jobs
>> > GrContext.o
>> > /new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mozilla/config/recurse.mk:74:
>> > recipe for target 'media/libvpx/target' failed
>> >
>> > If I recall correctly, after fixing this bug by temporarily copying
>> > vp9_thread.o from |common| directory,
>> > I would get error of the other missing file.
>> >
>> > I am not sure why others don't encounter this bug. Maybe different
>> > mozconfig
>> > setup.
>> >
>> > TIA
>> >
>> > On 2014年10月25日 14:00, ISHIKAWA,chiaki wrote:
>>> > > On 2014/10/24 13:46, Anthony Jones wrote:
 > >> I just wanted to give a heads up to everyone that we enabled Media
 > >> Source Extensions on nightly for WebM/VP9. This brings Adaptive
 > >> Streaming capability to Firefox video playback. The feature is not
 > >> complete so the pref will automatically turn off when it gets to
 > >> beta/release if we do nothing.
 > >>
 > >> You can check on YouTube by right clicking the playing video and
 > >> selecting "Stats for nerds" which should appear above the "About the
 > >> HTML5 player" option. If you see "DASH: yes" then you are now living 
 > >> in
 > >> the future.
 > >>
 > >> This affects YouTube but may also affect sites that use MSE with
 > >> WebM/VP9 but it could also affect sites that use MSE but fail to check
 > >> codec compatibility.
 > >>
 > >> Please file any (unfiled) issues you experience as blocking bug 
 > >> 1083588.
 > >> Don't expect it to be perfect and if you run into trouble you can set
 > >> media.mediasource.enabled to false in your about:config
 > >>
 > >> Anthony
>>> > >
>>> > >
>>> > > Hi,
>>> > >
>>> > > Just reporting what I observed after a source refresh half a day ago.
>>> > >
>>> > > I noticed during C-C TB compilation
>>> > > a file under common needs to be copied to encoder, another one to 
>>> > > decoder
>>> > > directory .
>>> > > I am talking about files below these directories.
>>> > > mozilla/media/libvpx/vp9/{common,encoder,decoder}
>>> > >
>>> > > But since C-C was in such a disarray in terms of compilation lately,
>> > etc.,
>>> > > and the source was refreshed just before this compilation effort,
>>> > > I am not sure if the configuration was quite correct.
>>> > > I failed to write down a memo exactly which files were
>>> > > copied. I thought I was logging it using script, but did not.
>>> > > I clobbered and then tried to see how it would work out, and then was
>>> > > side-tracked by bug 1088497
>>> > >
>>> > > I can compare the directory to report what files were copied
>>> > > if no such bugs have been filed yet and you are not aware of the issue.
>>> > > (I tried to see which one by timestamp, but python client.py checkout
>>> > > seems to give same timestamps to all the files and so I am not sure 
>>> > > which
>>> > > ones were copied. cp or Emacs's filecopy seems to preserve the 
>>> > > timestamp.
>>> > > That is good sometimes, but annoying sometimes.)
>>> > >
>>> > > But then again, I am not entirely sure if it was a temporal hiccup after
>>> > > the source refresh.
>>> > >
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: MSE WebM/VP9 enabled on nightly

2014-10-27 Thread Bobby Holley 
This issue is off-topic for this thread. Please file a bug and CC a build
peer.

On Mon, Oct 27, 2014 at 10:06 AM, ishikawa  wrote:

> Sorry for top-posting:
>
> The error mentioned about the missing files was again observed on a PC
> which has C-C tree refreshed this morning.
>
> The error for one of the file is as follows:
>
> make[4]: *** No rule to make target
>
> '/new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mozilla/media/libvpx/vp9/decoder/vp9_thread.c',
> needed by 'vp9_thread.o'.  Stop.
> make[4]: *** Waiting for unfinished jobs
> GrContext.o
> /new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mozilla/config/recurse.mk:74:
> recipe for target 'media/libvpx/target' failed
>
> If I recall correctly, after fixing this bug by temporarily copying
> vp9_thread.o from |common| directory,
> I would get error of the other missing file.
>
> I am not sure why others don't encounter this bug. Maybe different
> mozconfig
> setup.
>
> TIA
>
> On 2014年10月25日 14:00, ISHIKAWA,chiaki wrote:
> > On 2014/10/24 13:46, Anthony Jones wrote:
> >> I just wanted to give a heads up to everyone that we enabled Media
> >> Source Extensions on nightly for WebM/VP9. This brings Adaptive
> >> Streaming capability to Firefox video playback. The feature is not
> >> complete so the pref will automatically turn off when it gets to
> >> beta/release if we do nothing.
> >>
> >> You can check on YouTube by right clicking the playing video and
> >> selecting "Stats for nerds" which should appear above the "About the
> >> HTML5 player" option. If you see "DASH: yes" then you are now living in
> >> the future.
> >>
> >> This affects YouTube but may also affect sites that use MSE with
> >> WebM/VP9 but it could also affect sites that use MSE but fail to check
> >> codec compatibility.
> >>
> >> Please file any (unfiled) issues you experience as blocking bug 1083588.
> >> Don't expect it to be perfect and if you run into trouble you can set
> >> media.mediasource.enabled to false in your about:config
> >>
> >> Anthony
> >
> >
> > Hi,
> >
> > Just reporting what I observed after a source refresh half a day ago.
> >
> > I noticed during C-C TB compilation
> > a file under common needs to be copied to encoder, another one to decoder
> > directory .
> > I am talking about files below these directories.
> > mozilla/media/libvpx/vp9/{common,encoder,decoder}
> >
> > But since C-C was in such a disarray in terms of compilation lately,
> etc.,
> > and the source was refreshed just before this compilation effort,
> > I am not sure if the configuration was quite correct.
> > I failed to write down a memo exactly which files were
> > copied. I thought I was logging it using script, but did not.
> > I clobbered and then tried to see how it would work out, and then was
> > side-tracked by bug 1088497
> >
> > I can compare the directory to report what files were copied
> > if no such bugs have been filed yet and you are not aware of the issue.
> > (I tried to see which one by timestamp, but python client.py checkout
> > seems to give same timestamps to all the files and so I am not sure which
> > ones were copied. cp or Emacs's filecopy seems to preserve the timestamp.
> > That is good sometimes, but annoying sometimes.)
> >
> > But then again, I am not entirely sure if it was a temporal hiccup after
> > the source refresh.
> >
> > Just an observation.
> >
> > TIA
> >
> >
> >
> > TIA
> >
> ___
> 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: MSE WebM/VP9 enabled on nightly

2014-10-27 Thread ishikawa 
Sorry for top-posting:

The error mentioned about the missing files was again observed on a PC
which has C-C tree refreshed this morning.

The error for one of the file is as follows:

make[4]: *** No rule to make target
'/new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mozilla/media/libvpx/vp9/decoder/vp9_thread.c',
needed by 'vp9_thread.o'.  Stop.
make[4]: *** Waiting for unfinished jobs
GrContext.o
/new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mozilla/config/recurse.mk:74:
recipe for target 'media/libvpx/target' failed

If I recall correctly, after fixing this bug by temporarily copying
vp9_thread.o from |common| directory,
I would get error of the other missing file.

I am not sure why others don't encounter this bug. Maybe different mozconfig
setup.

TIA

On 2014年10月25日 14:00, ISHIKAWA,chiaki wrote:
> On 2014/10/24 13:46, Anthony Jones wrote:
>> I just wanted to give a heads up to everyone that we enabled Media
>> Source Extensions on nightly for WebM/VP9. This brings Adaptive
>> Streaming capability to Firefox video playback. The feature is not
>> complete so the pref will automatically turn off when it gets to
>> beta/release if we do nothing.
>>
>> You can check on YouTube by right clicking the playing video and
>> selecting "Stats for nerds" which should appear above the "About the
>> HTML5 player" option. If you see "DASH: yes" then you are now living in
>> the future.
>>
>> This affects YouTube but may also affect sites that use MSE with
>> WebM/VP9 but it could also affect sites that use MSE but fail to check
>> codec compatibility.
>>
>> Please file any (unfiled) issues you experience as blocking bug 1083588.
>> Don't expect it to be perfect and if you run into trouble you can set
>> media.mediasource.enabled to false in your about:config
>>
>> Anthony
> 
> 
> Hi,
> 
> Just reporting what I observed after a source refresh half a day ago.
> 
> I noticed during C-C TB compilation
> a file under common needs to be copied to encoder, another one to decoder
> directory .
> I am talking about files below these directories.
> mozilla/media/libvpx/vp9/{common,encoder,decoder}
> 
> But since C-C was in such a disarray in terms of compilation lately, etc.,
> and the source was refreshed just before this compilation effort,
> I am not sure if the configuration was quite correct.
> I failed to write down a memo exactly which files were
> copied. I thought I was logging it using script, but did not.
> I clobbered and then tried to see how it would work out, and then was
> side-tracked by bug 1088497
> 
> I can compare the directory to report what files were copied
> if no such bugs have been filed yet and you are not aware of the issue.
> (I tried to see which one by timestamp, but python client.py checkout
> seems to give same timestamps to all the files and so I am not sure which
> ones were copied. cp or Emacs's filecopy seems to preserve the timestamp.
> That is good sometimes, but annoying sometimes.)
> 
> But then again, I am not entirely sure if it was a temporal hiccup after
> the source refresh.
> 
> Just an observation.
> 
> TIA
> 
> 
> 
> TIA
> 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Firefox 2.2.0 and everything.me

2014-10-27 Thread Gabriele Svelto 
On 27/10/2014 09:55, Karl Dubost wrote:
> 1. Being usability (performance on flickering) Bug number?

We've got bug 1027381 [1] though we might want to introduce a mechanism
to also throttle the requests we send (and drawing the spinner which
takes a huge amount of CPU time slowing down the user). I had
implemented a simple solution for the old browser search bar in bug
985369 [2], it could be used as an inspiration for improving the
Rocketbar search though as I mentioned above one would need to do more
there than simple throttling because the spinner alone is a huge drag on
performance.

 Gabriele

[1] [SCR][Rocketbar] Can we do a reduction of flashing via a comparison
with this found set versus last found set?
https://bugzilla.mozilla.org/show_bug.cgi?id=1027381
[2] Writing into the URL bar consumes 100% CPU time
https://bugzilla.mozilla.org/show_bug.cgi?id=985369



signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Firefox 2.2.0 and everything.me

2014-10-27 Thread Karl Dubost 
Gabriele,


Le 27 oct. 2014 à 09:48, Gabriele Svelto  a écrit :
> Yes, suggestions can be disabled from the settings app: go into Settings
> Search and turn off "Search Suggestions". 

Thanks! Very useful.

So that solves one part of the issues. Very cool. I had completely missed it.
Next time someone is asking me, I can inform them.

The two other issues:
1. Being usability (performance on flickering) Bug number?
2. Change of expectations. More difficult I guess. Maybe during the intro after 
updating to a new version, explaining the new features and their consequences.

Thanks again.

-- 
Karl Dubost, Mozilla
http://www.la-grange.net/karl/moz

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

Re: Firefox 2.2.0 and everything.me

2014-10-27 Thread Gabriele Svelto 
On 27/10/2014 08:08, Karl Dubost wrote:
> 2. It seems to be a change of policy in terms of sharing data the user type 
> in the URL bar. Is there a possibility to put that off and not having 
> whatever you type up there to be sent somewhere the user does not expect?

Yes, suggestions can be disabled from the settings app: go into Settings
> Search and turn off "Search Suggestions". This should stop search
suggestions from the URL/RocketBar while giving you the possibility of
manually starting a search.

 Gabriele




signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Firefox 2.2.0 and everything.me

2014-10-27 Thread Karl Dubost 
Andreas,

Le 27 oct. 2014 à 09:30, Andreas Gal  a écrit :
> So we send an XHR request for each letter to Google on Desktop (search box), 
> and XHR requests to e.me on Firefox OS. How are these cases different. Are 
> they both a problem? I am just trying to understand the exact nature of your 
> concern.

OK quoting myself.

Le 27 oct. 2014 à 08:08, Karl Dubost  a écrit :
> 1. experience-wise it is annoying to have the flickering of icons for each 
> letter typed.

Poor user experience. This might be solvable.


> 2. It seems to be a change of policy in terms of sharing data the user type 
> in the URL bar. Is there a possibility to put that off and not having 
> whatever you type up there to be sent somewhere the user does not expect?

The nature of concerns here is two folds:

1. Can users deactivate everything.me ? 
   Users can change the default search engine on Firefox Desktop. Users have 
the choice to never use or use only $SEARCH_ENGINE_BRAND if they wish so. 
That's a cool feature: Have the choice.

2. Change of expectations.
   A user which was using Firefox OS 1.0 to 1.3 could use the search feature of 
everything.me OR the browser URL bar. Now the user has only one bar which is 
sending data to a service which he/she didn't opt-in. (A bit what is happening 
with Spotlight on 10.10)


The issue is never to propose a feature. That is cool if people need it. The 
issue is more:
1. To make the feature without the choice to not deactivate it.
2. To change expectations on the sharing perimeter of a feature.


Does it make more sense? ^_^ (maybe my French is getting into the way).


-- 
Karl Dubost, Mozilla
http://www.la-grange.net/karl/moz

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

Re: Firefox 2.2.0 and everything.me

2014-10-27 Thread Andreas Gal 

> On Oct 27, 2014, at 1:16 AM, Karl Dubost  wrote:
> 
> Andreas,
> 
> Le 27 oct. 2014 à 08:15, Andreas Gal  a écrit :
>> What happens when a user types letters into the Google search box we ship by 
>> default in Firefox?
> 
> Do you mean desktop? Sorry I was not clear, but I was talking about Firefox 
> OS.
> But that seems unrelated to everything.me
> 
> 
> About Desktop:
> * For Google search box on Desktop, I suspect the one which is available in 
> the initial tab (center of the page) is also sending XHR requests to Google 
> for each letter.
> * For the URL bar, it seems it does not send anything. At least it doesn't 
> suggest anything. It will send to Google keywords which are not URIs, once 
> you have typed "enter"
> 
> At least that is my understanding.

So we send an XHR request for each letter to Google on Desktop (search box), 
and XHR requests to e.me  on Firefox OS. How are these cases 
different. Are they both a problem? I am just trying to understand the exact 
nature of your concern.

Thanks,

Andreas

> 
> 
> -- 
> Karl Dubost, Mozilla
> http://www.la-grange.net/karl/moz
> 

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

Re: Firefox 2.2.0 and everything.me

2014-10-27 Thread Karl Dubost 
Andreas,

Le 27 oct. 2014 à 08:15, Andreas Gal  a écrit :
> What happens when a user types letters into the Google search box we ship by 
> default in Firefox?

Do you mean desktop? Sorry I was not clear, but I was talking about Firefox OS.
But that seems unrelated to everything.me


About Desktop:
* For Google search box on Desktop, I suspect the one which is available in the 
initial tab (center of the page) is also sending XHR requests to Google for 
each letter.
* For the URL bar, it seems it does not send anything. At least it doesn't 
suggest anything. It will send to Google keywords which are not URIs, once you 
have typed "enter"

At least that is my understanding.


-- 
Karl Dubost, Mozilla
http://www.la-grange.net/karl/moz

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

Re: Firefox 2.2.0 and everything.me

2014-10-27 Thread Andreas Gal 
What happens when a user types letters into the Google search box we ship by 
default in Firefox?

Thanks,

Andreas

> On Oct 27, 2014, at 12:08 AM, Karl Dubost  wrote:
> 
> In Firefox 2.2.0, each time you try to enter a letter, there are a list of 
> icons displayed which seems to be delivered by Everything.me.
> 
> I see two issues:
> 
> 1. experience-wise it is annoying to have the flickering of icons for each 
> letter typed.
> 
> 2. It seems to be a change of policy in terms of sharing data the user type 
> in the URL bar. Is there a possibility to put that off and not having 
> whatever you type up there to be sent somewhere the user does not expect?
> 
> Maybe there are bugs for this.
> Thanks.
> 
> -- 
> Karl Dubost, Mozilla
> http://www.la-grange.net/karl/moz
> 
> ___
> 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

Firefox 2.2.0 and everything.me

2014-10-27 Thread Karl Dubost 
In Firefox 2.2.0, each time you try to enter a letter, there are a list of 
icons displayed which seems to be delivered by Everything.me.

I see two issues:

1. experience-wise it is annoying to have the flickering of icons for each 
letter typed.

2. It seems to be a change of policy in terms of sharing data the user type in 
the URL bar. Is there a possibility to put that off and not having whatever you 
type up there to be sent somewhere the user does not expect?

Maybe there are bugs for this.
Thanks.

-- 
Karl Dubost, Mozilla
http://www.la-grange.net/karl/moz

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