Re: Intent to implement and ship: Limit the length of Referer header to 4k

[Panos Astithas]

On Tue, Jul 2, 2019 at 6:16 AM Thomas Nguyen  wrote:

> DevTools bug: No
>

 Wouldn't it be helpful to indicate such truncation in the console (as a
warning) or network panel (with a request badge)? I can imagine developers
being confused about why the referrer header is not what they expect it to
be.

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

Performance profiling improvements #3

[Panos Astithas]

Hello folks!

It has been another 3 months since our last update on the Firefox Profiler.
During this time the Performance Tools team and our brilliant contributors
have made many improvements that should make using the tool a more
delightful experience.

Here are the highlights:

# New Categorized Activity Timeline
Perhaps the most prominent change is that the default graph format has
changed. Instead of displaying a bar graph of the sampled stack length, the
tool now shows the type of activity that occurred at a specific point in
time (blue: DOM, purple: layout, green: graphics, yellow: JS, orange:
GC/CC, gray: other, empty: idle). You can switch between the activity graph
and the stack graph using the radio buttons above the thread & process list.

# Navigate faster with the Loupe View
For those used to timelines in movie editing software, there is an
additional timeline view at the top of the call tree panel that combines
the category view with an inverted stack chart view. You can use it to
quickly navigate the selected thread’s timeline: shift+scroll to zoom,
scroll to pan, click to focus the call tree on the selected area.

# Dimmed idle stacks
When selecting the traditional stack graph view, idle stacks are now
dimmed, making it easier to focus on the profile areas that matter.

# Grouped thread & track list
The thread list has also been updated to group the main thread of each
process with the other threads in the same process. Furthermore, there will
be additional tracks for network traffic per process that focus the network
panel on selection, where one can inspect the requests made in that
process. The grouping and the extra tracks are also selectable in the
context menu when right-clicking on the thread list, where you can also
select to display any idle threads that are automatically hidden by
default. Unhiding threads can be useful when one is interested in the 1% of
non-idle activity that occurs in a predominantly idle thread.

# Screenshot capturing (OSX only, more coming!)
On macOS systems with Web Render disabled, the profiler add-on has an
additional setting to capture screenshots of the open windows. This should
help understand to what visual state of the browser the various events
correspond. Support for more platforms will come in the future.

# Filter across all panels
All six bottom panels can now be filtered by specific strings that will
limit the display to the stacks or markers containing said string.

# Import native `perf` traces
Two of the current limitations of the profiler are that it can’t profile
the very early phase of browser startup (before the profiler code has been
initialized) and that it imposes some small overhead when recording. The
overhead increases when one increases the number of sampled threads. One
nice workaround for both problems that still lets you use the profiler UI
to investigate is recording a profile on Linux with the ‘perf’ tool and
then importing the output from https://perf-html.io/. The profiler can
parse the recorded profile and display the aggregated stacks (but of course
without markers). To record a profile with the ‘perf’ command run the
following commands and then load the firefox.symbol.data output file from
https://perf-html.io:
> sudo perf record -g -F 999 -p 
> sudo perf script -F +pid > firefox.symbol.data

# Remote profiling for Gecko on Android
Finally, profiling Fennec or GeckoView nightlies has been improved, by
removing the overhead imposed by devtools and adding symbols for native
Android libraries. Documentation on remote profiling Android is available
at https://perf-html.io/docs/#/./guide-remote-profiling

We would like to encourage everyone to try these new features out and let
us know of anything that we could improve. If you come across a performance
bug while you are at it, please remember to file a bug and tag it with [qf]
in the whiteboard. Our performance team will be happy to investigate.

Happy profiling!

Panos, on behalf of the perf tools team
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: mercurial-setup becomes vcs-setup and adds support for git

[Panos Astithas]

The --git flag to |mach vcs-setup| was short-lived after all. I've landed
bug 1484243 in autoland (thanks ahal!), so it will now figure out what VCS
is being used and do the right thing. When it merges to m-c you can forget
it was ever there.

Cheers,
Panos



On Fri, Aug 17, 2018 at 7:54 AM Andrew Halberstadt  wrote:

> This is awesome, thanks for working on it! I filed a follow-up to
> detect the vcs automatically (bug 1484243).
>
> In the meantime, if you are a git user you can create an alias in
> ~/.mozbuild/machrc:
> [alias]
> vcs-setup = vcs-setup --git
>
> On Fri, Aug 17, 2018 at 3:51 AM Panos Astithas  wrote:
>
>> Hi all,
>>
>> since bug 1257478 landed in m-c earlier today, you should now be using
>> 'mach vcs-setup' instead of 'mach mercurial-setup'. Nothing else changes in
>> your workflow (e.g. 'mach mercurial-setup -u' becomes 'mach vcs-setup -u')
>> and the spell checker will suggest vcs-setup if you try to use
>> mercurial-setup.
>>
>> If you are a git-cinnabar user, your workflow is now supported. 'mach
>> vcs-setup --git' will fetch the latest recommended version of git-cinnabar
>> and configure it for you. The --update-only flag is also available for git,
>> so it would be a good idea to run 'mach vcs-setup --git --update-only' (or
>> 'mach vcs-setup -gu') every now and then to make sure everything is up to
>> date.
>>
>> 'mach bootstrap' will also offer to update and configure your
>> git-cinnabar environment if a git checkout is detected.
>>
>> Cheers,
>> Panos
>>
>> ___
>> firefox-dev mailing list
>> firefox-...@mozilla.org
>> https://mail.mozilla.org/listinfo/firefox-dev
>>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

PSA: mercurial-setup becomes vcs-setup and adds support for git

[Panos Astithas]

Hi all,

since bug 1257478 landed in m-c earlier today, you should now be using
'mach vcs-setup' instead of 'mach mercurial-setup'. Nothing else changes in
your workflow (e.g. 'mach mercurial-setup -u' becomes 'mach vcs-setup -u')
and the spell checker will suggest vcs-setup if you try to use
mercurial-setup.

If you are a git-cinnabar user, your workflow is now supported. 'mach
vcs-setup --git' will fetch the latest recommended version of git-cinnabar
and configure it for you. The --update-only flag is also available for git,
so it would be a good idea to run 'mach vcs-setup --git --update-only' (or
'mach vcs-setup -gu') every now and then to make sure everything is up to
date.

'mach bootstrap' will also offer to update and configure your git-cinnabar
environment if a git checkout is detected.

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

Performance profiling improvements #2

[Panos Astithas]

Hello there!

It has been almost 3 months since our last update on the Firefox Profiler.
In that time the Performance Tools team and our awesome contributors have
made numerous improvements that will hopefully make your jobs easier, for
all of you trying to make Firefox fast, for good.

Here are the highlights:

   -

   First of all we added documentation 
   including short videos, on how to use the profiler and some case studies
   about how performance investigations are often conducted. You can find
   links to the docs in the button list above the timeline and in the
   perf-html.io landing page.
   -

   Secondly, we added a new Network tab that contains information about the
   network requests that occurred during profiling. We plan to make this new
   panel look more like the devtools network panel soon.
   -

   Since the profiler can now collect network requests that sometimes
   contain privacy-sensitive information, the Share button has an additional
   checkbox in the popup panel to choose whether to include these network
   requests in the uploaded profile. This checkbox is unchecked by default to
   protect user privacy. If a profile has been shared without network
   information by mistake (and vice versa), an additional button to "Share
   with URLs" (or "Share without URLs") will appear next to the Permalink
   button.
   -

   There is also a new sidebar that can be opened from the button on the
   right side of the tab list to inspect individual stack frames in the Call
   Tree and Flame Graph, and soon in the rest of the panels as well.
   -

   The Call Tree now displays an activity category indicator (a colored
   box) next to the stack frame. The category types are color-coded and
   hovering over the colored box displays the category name in a tooltip (JS,
   Graphics, Layout, etc.). Soon we will start displaying the activity
   information in the thread timelines, which will make it easier to find the
   interesting parts at a glance.
   -

   Another useful visual polish is that selecting a time range by dragging
   the cursor over the timeline will now display the time range duration in
   the time breadcrumb bar. Zooming in on this range will add the duration to
   the breadcrumb bar, while deselecting the range will make it disappear.
   -

   The profiler is now smarter about idle threads that are rarely useful to
   inspect and hides them by default. They can be shown again using the thread
   context menu (right click on the thread list).
   -

   For things the profiler can't be smart about, we added configuration
   options to better fit the various use cases. The add-on panel used for
   starting and stopping the profiler now includes options to use a single
   thread for Stylo (sequential styling) and disable responsiveness probes,
   among others.
   -

   In that same panel, it is now possible to profile all threads of a
   specific process, instead of the specified threads in every process. The
   syntax to use for the former is, for example |pid=1234|, whereas the syntax
   for the latter is e.g. |GeckoMain,Compositor,StyleThread|.
   -

   Finally there is now support for profiling Fennec, by following the
   instructions in the docs
   . Soon we expect
   to be able to profile Focus Nightly that ships with GeckoView.


Feel like taking the profiler for a spin to check out all these new
features? That’s fantastic! While you do that, if you spot anything that
seems to be suboptimal, please file a bug and tag it with [qf] in the
whiteboard. Our performance team is eager for more performance bugs to
triage.

Happy profiling!

Panos, on behalf of the perf tools team
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: Web Performance Working Group

[Panos Astithas]

On Wed, Jul 11, 2018 at 4:52 PM Tom Ritter  wrote:

> Device Memory clearly has made an effort to make it 'less fingerprintable'
> by only reporting possible values of 0.25, 0.5, 1, 2, 4, 8 - but there is
> nothing in the spec about omitting it if desired to reduce fingerprinting.
> This is a spec issue though, and not a rechartering one I don't think.
>

Would a privacy-conscious user prefer to get the full site experience or a
reduced one? I assume they would rather get the full experience without
divulging any additional information. In that case wouldn't it be better to
just send the maximum allowed value (8) instead of adding another 7th
possible value (like null)?

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

Re: Proposed W3C Charter: Web Performance Working Group

[Panos Astithas]

Thanks everybody for the comments submitted so far on the WG rechartering
process, please keep them coming!

I would like to make two requests, if I may:
- feedback on specs and not on the recharter should be submitted to the
GitHub issue tracker for the spec (ping me if you can't find it)
- if you have any feedback that you would like me to voice in the WG calls,
please send me a note with the specifics.

Also, if anybody is interested in participating in the WG calls and
actively shaping the conversations, please let me know! I would very much
appreciate the help.

Thanks,
Panos


On Wed, Jul 11, 2018 at 11:30 PM Randell Jesup 
wrote:

> >Adding to what Tom said...
> >
> >1. "Web developers want the ability to observe the performance
> >characteristics of their applications" - they want to do so, but
> >*should* they be allowed to do so? The API would give access to deep
> >performance data that could be used for all sorts of nefarious purposes
> >(profiling, fingerprinting, probing for vulnerabilities, etc.).
>
> The extreme version of this is what Vlad and Benoit (Facebook) have
> proposed in WICG, which is an interface to profiling data for the page
> (origin): https://github.com/vdjeric/js-self-profiling
> Discussion (mozilla) here:
> https://github.com/mozilla/standards-positions/issues/92
>
> One can understand why they'd *want* to be able to profile their code
> in-the-field.
>
> Exposing this today would be have serious same-origin and Spectre
> impacts; in a Fission world these problematic impacts would be (more)
> limited though perhaps not "safe".  (Implied in the current Gecko
> Profiler impl is that other processes could affect how fast your
> origin's process runs, and thus how much progress is made between
> profiler 'ticks',leading to some leakage of information cross-orgin
> between processes.  How large an impact this is I'm not 100% sure at
> this point. If we changed sampling to be runtime-based instead of
> wallclock-based, this (mostly) hides the impact of other processes,
> though secondary effects still exist (cache impacts, etc).
>
> Making it runtime-based would be a largish change...
>
> --
> 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

Performance profiling improvements

[Panos Astithas]

Hello!

As we continue our relentless focus on improving Firefox performance, I
would like to call your attention to some related improvements in our tools
that occurred over the last few months.

First of all, the performance tools team and the automation team worked
together to make perf.html  and treeherder
 more integrated. The result is that now
perf.html can load zip files from try with Talos profiles and display them,
while treeherder now displays links to perf.html in Talos jobs that record
a profile. Performance sheriffs have started including links to these
profiles in Talos regression reports, but you can also get them on try by
running |./mach try fuzzy --talos-profile| (here

is an example).

We encourage everyone to generate profiles before landing their changes, to
make sure Firefox performance doesn't regress. A good strategy is to
generate two profiles, one before landing the change and one after. When
you then open them side by side, it will be much easier to see what impact
your changes had.

The Gecko Profiler itself has received some notable improvements (apart
from the regular speedups and bug fixes):

   - There is a new Flame Graph* visualization that provides a summary view
   of which stack frames consumed the most CPU. What you are looking for here
   is long dark nodes: the length indicates the relative percentage in the
   profile and the darker colors indicate higher self-time (with a different
   hue for native vs. JS frames). This is different from the similar Stack
   Chart view that gives you a time-based view of code execution. Both have
   their advantages, so combining them can lead to better insights. Summary
   views can also be very valuable when comparing profiles.


   - The profiler now collects network request information that can be seen
   in the Marker Chart. This visualization is a first rough cut; expect more
   intuitive views and better filtering there. But you can already use it to
   see when Firefox is blocked on a network request and how network loads
   correlate with page rendering.

If you encounter any problems while using the profiler, please file
them in Core::Gecko
Profiler

(for backend bugs) or open an issue
 on GitHub for UI
improvements. And if you have any feedback on the treeherder/profiler
integration, don't hesitate to drop me a note.

Happy profiling!

Panos

*: you can learn more about flame graphs from their inventor Brendan Gregg
at http://www.brendangregg.com/flamegraphs.html
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to require `mach try` for submitting to Try

[Panos Astithas]

On Tue, Sep 19, 2017 at 7:20 PM, Andrew McCreight 
wrote:

> I've been using git for years now to develop Firefox, and I feel like it is
> a first class experience. There's a one time cost to setting up cinnabar,
> but after that, everything just works, including |mach try| and |mach
> mozreview|. It is still probably less setup than Mercurial users have to go
> through to install enough extensions to make hg usable. ;) Sure, there's a
> bit of "wacky custom machinery", but developers using hg also have to deal
> with some of that, so that's more of a Firefox developer problem than a git
> Firefox developer problem.


The experience with git-cinnabar has been pretty smooth for me, too. If we
could make the tool update process match the mercurial experience (mach
mercurial-setup -u), it would be great. I was planning to work on this, but
the long-term plans seemed unclear at the time:

https://bugzilla.mozilla.org/show_bug.cgi?id=1257478

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

Re: Firefox 55.* in Windows/Ubuntu - every day CPU 100%/Hangs Up. Please to do something!

[Panos Astithas]

Hi,

if you could file a bug, we can try to figure this out:

https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox=Untriaged

Please attach the contents of about:support as an attachment, so we can get
some idea of your configuration.

Thanks,
Panos


On Wed, Sep 6, 2017 at 10:45 AM, Alexey Zvyagin 
wrote:

> Dear developers of Firefox,
>
> I have 55.* version of Firefox at work and at home
> At work i have Windows 7 OS, at home the Ubuntu 16.04 LTE
> I have my own synced profile. I don't have problem with syncing...
>
> In both OSes i regulary and every day i see the situation when after few
> work time (may be even after 1-5 minutes) of Firefox i see the CPU 100% of
> Firefox and the Firefox hangs up after... Only one way i have for repairing
> of this: "killall -HUP firefox" command at Ubuntu and "End Task" in Windows.
>
> In both cases i have turned on option about "report health" and about
> "reports to Mozilla". I know about the page "about:crashes" and regulary to
> see there. The main problem is there: this hangings up cases are not
> generated there. When i killed the Firefox and restarted its i didn't see
> fresh some reports in "about:crashes". I tried to tun on safe mode too. In
> safe mode the Firefox has same buggy behaviour - after some minutes it
> starts to eat 100% of CPU and no responding after... And again in
> "about:crashes" doesn't have there any fresh generated reports
> (about:crashes sometime has reports there which were created by other
> situation - may be by like "segmentation faults" errors).
>
> I conclude that this "CPU bug" is not reported to you in many user cases!
> And i conclude that this is global problem (some OSes) not related with
> hardware and plugins.
>
> I don't know how to report about this to you. I love your browser but your
> last version (55.0.2 & 55.0.3) are very very buggy. This is very annoying!
>
> Best regards, Alexey
> ___
> 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: Stylesheet wait timeout?

[Panos Astithas]

On Fri, Sep 1, 2017 at 7:37 PM, Boris Zbarsky  wrote:

> I reported this issue to them (copy/paste of my report below) through the
> form at https://ghostery.zendesk.com/hc/en-us/requests/new but if someone
> has better contact info that might be nice.
>

I have forwarded your message to my contacts at Cliqz (new owners of
Ghostery) and pointed them to this thread as well.

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

Re: Have you run 'mach bootstrap' lately?

[Panos Astithas]

I had filed bug 1257478 specifically for tackling the git configuration
issue and when this larger plan was brought up, my inclination to work on
it diminished :) If this broader work is not prioritized, could we split it
into smaller bugs so that it's manageable in weekend-sized chunks? I
realize there will be some temporary churn (e.g. a not very long-lived
'mach git-setup'), but we could get at the final goal faster.

Panos


On Tue, May 16, 2017 at 3:38 AM, Gregory Szorc  wrote:

> I thought there was a bug on file, but maybe not. I've long thought the
> following changes should be made:
>
> * `mach mercurial-setup` should be rolled into `mach bootstrap`
> * `mach doctor` should be rolled into `mach bootstrap`
> * `mach bootstrap` should remember answers from last time and not prompt on
> subsequent runs unless a flag is specified
> * `mach bootstrap` should be renamed/aliased to `mach refresh` (or similar)
> to reflect that it is no longer limited to initial system setup
>
> And of course there are missing features, such as Git configuration and
> offering to create a Git clone.
>
> bootstrap, doctor, and mercurial-setup are all under-loved features. They
> tend to not get prioritized very highly. Typically, new features or bug
> fixes are implemented when someone feels like scratching an itch. I wish I
> could justify spending more time on these things because turnkey optimal
> development environments are important. But it's a lot of ongoing work and
> there always seems to be something else competing for my time :(
>
> On Mon, May 15, 2017 at 4:59 PM, Ralph Giles  wrote:
>
> > The stand-alone bootstrap.py script actually has a --no-interactive
> > option (which answers 'yes' to everything) but the mach wrapper
> > doesn't support this.
> >
> > `mach mercurial-setup` takes an --update-only option. Maybe we
> > implementing something like that for `mach boostrap` would help. Or
> > calling it something more descriptive like `mach update-deps`. Like
> > mercurial-setup, it could still use the bootstrap python module to
> > install things. While the two use cases are different, it makes sense
> > to share code between an initial development environment setup script
> > and one that updates that environment.
> >
> >  -r
> >
> > On Mon, May 15, 2017 at 3:39 PM, Ethan Glasser-Camp
> >  wrote:
> > > Actually, I think my real question is "What is the intended way for
> > > developers to keep their development environment up-to-date?" I don't
> > think
> > > that way should require a developer to answer questions, because the
> > > answers presumably haven't changed since the last time they answered
> > them.
> > > If the intended way is `mach bootstrap`, then I think `mach bootstrap`
> > > should have an option to skip the questions[*]. If `mach bootstrap` is
> > only
> > > intended to run once when setting up a new development environment,
> then
> > > maybe there should be a `mach tune-up` command or something like that.
> > >
> > > I'm happy to file bugs for whichever is the case, but I'm not sure
> which
> > > one it is.
> > >
> > > Ethan
> > >
> > > [*] When using `./mach bootstrap --settings ./mozconfig`, I get: `The
> > > bootstrap command does not accept the arguments: --settings
> ./mozconfig`.
> > > When using `./mach --settings ./mozconfig bootstrap`, I get the
> > questions.
> > >
> > >
> > > On Fri, May 12, 2017 at 1:04 PM, Geoffrey Brown 
> > wrote:
> > >
> > >> I'm not sure. I always just answer the prompts and am happy with that.
> > >>
> > >> There is a --settings option, which sounds like it might be helpful,
> > but I
> > >> don't have any experience with that.
> > >>
> > >>  - Geoff
> > >>
> > >> On Fri, May 12, 2017 at 9:00 AM, Ethan Glasser-Camp <
> > >> eglasserc...@mozilla.com> wrote:
> > >>
> > >>> Is there a way to run it without having to reanswer the configuration
> > >>> questions?
> > >>>
> > >>> Ethan
> > >>>
> > >>>
> > >>
> > > ___
> > > 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
> >
> ___
> 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: Startup JS debugging (sometimes) possible via Browser Toolbox

[Panos Astithas]

You almost completely resolved the 4-year-old bug 814298, yay! I now wonder
if this makes it easier to improve mochitest debugging per bug 929535.

On Wed, Mar 8, 2017 at 9:22 PM, Kris Maglione  wrote:

> On Wed, Mar 08, 2017 at 01:09:10PM -0600, J. Ryan Stinnett wrote:
>
>> With bug 1275942 in Firefox 55, a new Firefox CLI option was added:
>> `--wait-for-jsdebugger`.
>>
>> ...
>>
>> Let me know if it's useful and / or you see room for improvement.
>>
>
> To put it one way: if we are ever in the same room, I owe you all of your
> drinks for the night.
>
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Converting assertions into release assertions

[Panos Astithas]

On Thu, Sep 22, 2016 at 6:07 PM, Ehsan Akhgari 
wrote:

> On 2016-09-22 9:07 AM, Gijs Kruitbosch wrote:
> > On 22/09/2016 05:28, Nicholas Nethercote wrote:
> >> Greetings,
> >>
> >> Assertions, such as MOZ_ASSERT, are great. But they only run in debug
> >> builds.
> >>
> >> Release assertions, such as MOZ_RELEASE_ASSERT, run in all builds.
> >>
> >> I want to highlight a nice case where converting a normal assertion
> >> into a release assertion was a win. In bug 1159244 Michael Layzell did
> >> this in nsTArray::ElementAt(), to implement a form of always-on array
> >> bounds checking. See
> >> https://bugzilla.mozilla.org/show_bug.cgi?id=1159244#c55 for
> >> discussion of how this is finding real bugs in the wild. (As well as
> >> identifying new bugs, it's also helping understand existing crash
> >> reports, e.g. see bug 1291082 where the crash signature changed.)
> >>
> >> Obviously we can't convert every normal assertion in the codebase into
> >> a release assertion. But it might be worth thinking about which normal
> >> assertions are good candidates for conversion. Good candidates include
> >> any assertion where the consequence of failure is dangerous, e.g.
> >> might cause memory access violations.
> >>
> >> Nick
> >
> > Yes please. This + diagnostic assert also helps frontend people who
> > build and run opt builds (because debug builds are too slow to be
> > usable, especially when combined with the browser toolbox (JS
> > debugging)). Right now I miss some of these and then only find out when
> > the tests that I did run go orange on try and/or inbound/autoland, and
> > then I have to locally change the relevant C++ so I can test in my opt
> > build (or resign myself to doing a separate clobber debug build
> somewhere).
>
> What exact debug configuration is too slow for you?  People who want to
> debug C++ generally turn optimizations off, but for front-end devs, I
> think building with --enable-debug and --enable-optimize should give you
> an optimized build with the debug facilities turned on, which should be
> much faster.  Although it is not going to be as fast as a
> --disable-debug --enable-optimize build, there's a lot of value in
> Mozilla developers running builds with debug checks turned on, so that
> we can get good bug reports when an assertion fires when working on a
> front-end feature, etc.
>

I used to do that in the past, but nowadays artifact builds have changed
the cost-benefit trade-off so very few people bother AFAIK, when not
touching C++ code. If we could get artifact builds to use --enable-debug
and --enable-optimize (or have an option to do so) that could change the
calculus.

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

Re: MXR permanently offline, please transition to DXR

[Panos Astithas]

It seems like the awesomebar could at least help you by boosting the
frecency weight of the new URL compared to the old one, so it can gradually
(or even not so gradually) be replaced. We are going to fix this in bug 737836.


Panos

On Fri, Jul 1, 2016 at 3:58 AM, Justin Dolske  wrote:

> This reminds me of a password manager bug we fixed 9 years ago (379997!),
> where password manager would "helpfully" delete a saved HTTP login if it
> got a 403 response upon using it. Unsurprisingly, this was a a terrible
> idea that caused your saved logins to disappear when a site was glitchy.
>
> Seem like it would be tough to find a solution to rewrite history/bookmarks
> that works when servers are nice, but also ignores servers that are
> naughty. Maybe this is addon-fodder for advanced users who want to
> mass-edit bookmarks and history.
>
> Justin
>
> On Thu, Jun 30, 2016 at 4:55 PM, Robert O'Callahan 
> wrote:
>
> > In theory responses 301 and 308 mean "permanent redirect" so the browser
> > could do that for those responses.
> >
> > In practice you'd need a lot of data to convince yourself that Web
> > developers haven't screwed this up too badly. Maybe 308, being newer, is
> > not compromised...
> >
> > Rob
> > --
> > lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe
> uresyf
> > toD
> > selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
> > rdsme,aoreseoouoto
> > o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
> > lurpr
> > .a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
> > esn
> > ___
> > 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
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: Changing the toString result on DOM prototype objects

[Panos Astithas]

On Fri, Jun 3, 2016 at 8:21 PM, Nick Fitzgerald 
wrote:

> On Fri, Jun 3, 2016 at 8:41 AM, Boris Zbarsky  wrote:
>
> > Devtools bug: none so far, but maybe we need one?  Does devtools rely on
> > the JSClass name or Object.prototype.toString anywhere?
> >
>
> ​I think we are fine. There are certainly places where we use the
> `Object.prototype.toString.call(thing) === "[object Whatever]"`​ hack, but
> I don't see any instances that would be tripped up by these changes.
>
>
> https://dxr.mozilla.org/mozilla-central/search?q=path%3Adevtools+%22toString.call(%22=false
>

Don't we still use the JSClass name in the variables view to indicate the
object type (reflected from Debugger.Object.prototype.class)?

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

Re: Intent to ship: Treat cookies set over non-secure HTTP as session cookies

[Panos Astithas]

On Fri, Apr 15, 2016 at 5:47 PM, Tantek Çelik 
wrote:

> However, As EKR pointed out, Kyle Huey's
>
> > Why should we be the ones to take the web compat hit on this?
>
> is the fundamentally biggest issue.
>

I realize I'm late to this thread and the discussion has moved the original
proposal towards something more refined and hence more likely to succeed,
but I'd still like to make a case for this tradeoff:

We should be the ones doing this, because we want to be known as the most
secure, most private browser.

This is isn't an easy position to reach or maintain. It's not as clear-cut
as the fastest browser, or the less memory-demanding browser, but it is one
we have identified as holding a competitive advantage for. Security and
privacy impact usability, that is a well-known fact, otherwise we'd all be
using Tor by now. So let's iterate on this or other similar proposals,
let's ship them off by default, let's provide great onboarding experiences,
documentation, whatever it takes, but let's not shy away from even trying.
Because what other path has a better chance to help us get to where we want
to be?

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

Re: How to change the default profile in the profile manager?

[Panos Astithas]

On Thu, Mar 24, 2016 at 4:53 PM, Tobias B. Besemer <
tobias.bese...@googlemail.com> wrote:

> Hi!
>
> I resorted/renamed my profile folders...
> Now, when I start the Developer Edition with the profile manager, FF
> creates a new entry with "dev-edition-default" and the according folders in
> \Roaming\Mozilla\Firefox\Profiles\ and \Local\Mozilla\Firefox\Profiles\
> (Win7).
> How to prevent this and maybe select a other profile the profile manager
> should point to as default?
>

It's not recommended, but see the "Reverting to Firefox Aurora" section
here:

https://developer.mozilla.org/Firefox/Developer_Edition/Reverting
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: CSS Mask Image properties

[Panos Astithas]

On Tue, Nov 10, 2015 at 9:09 AM, Ku(顧思捷)CJ  wrote:

> *Summary*:
> Intend to implement CSS mask. By using this it, you can apply a mask to a
> graphical object, so that the graphical object will be painted onto the
> background through a mask, thus completely or partially masking out parts
> of the graphical object.
>
> *DevTools bug*:
> none
>

It would be good to at least make sure our node highlighter behaves
properly in these cases. It might even be worthwhile to use a special mask
inspector, like we do for transforms.

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

Re: How would you like to spell check this?

[Panos Astithas]

On Thu, Sep 3, 2015 at 1:44 PM, Florian Quèze  wrote:

> On Sun, Aug 30, 2015 at 10:17 PM, Jörg Knobloch  wrote:
>
> > So please voice your objections to the proposed solution, if any ;-)
>
> As someone mentioned already, lots of websites are actually
> communication tools (eg. webmail, chat, social networks), and there's
> no way the website can know in advance in which language I'll want to
> type (I write half the time in French and half the time in English).
> My personal experience is that touching a context menu to switch the
> dictionary all the time is too much effort, so I gave up and am now
> used to completely ignoring the red underlines.
>
> The solution I would like to see implemented (and I'm willing to help)
> is automatic detection of the language. We already ship language
> detection code (
> http://mxr.mozilla.org/mozilla-central/source/browser/components/translation/LanguageDetector.jsm
> )
> and this could be reused for spell checking. Of course we can't guess
> the language when the user starts typing (so we'll still need the
> mechanisms you discussed), but as soon as we have a couple words, the
> detection is pretty reliable.
> This would of course need a way to pref it off for people who speak a
> single language and would be annoyed if every once in a while the
> dictionary is switched automatically; but I think it would make the
> spell checker significantly more usable for multi-language users.


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

Re: Intent to Implement: Selection Events

[Panos Astithas]

On Tue, Aug 18, 2015 at 6:21 PM, Michael Layzell mich...@thelayzells.com
wrote:

 Summary: We currently require webpages to poll the current selection when
 they want to be
 notified of changes to the user's selection.This patch adds two events,
 selectstart and
 selectionchange, which allow the website to detect when the selection is
 changed. selectstart
 is fired when the user starts selecting, and selectionchange is fired when
 the selection
 changes for any reason.

 Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=571294

 Link to standard:http://w3c.github.io/selection-api/#user-interactions

 Platform coverage:All platforms.

 Target release: Firefox 43.

 Preference behind which this will be implemented:
 dom.select_events.enabled

 DevTools bug: N/A


Listeners for these new events should be visible in the inspector [1] and
debugger [2] and the user should be able to break on them. I don't expect
any devtools changes will be needed to make this work, but I'm mentioning
it in order to be tested and verified.

Thanks,
Panos

[1]:
https://developer.mozilla.org/docs/Tools/Page_Inspector/How_to/Examine_event_listeners
[2]:
https://developer.mozilla.org/docs/Tools/Debugger/How_to/Break_on_a_DOM_event
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: Moving DevTools to top level /devtools directory

[Panos Astithas]

On Thu, Jul 23, 2015 at 8:25 AM, Paul Rouget p...@mozilla.com wrote:

 On Wed, Jul 22, 2015 at 2:48 PM, Panos Astithas p...@mozilla.com wrote:
  If you are thinking about shipping them as part of browser.html, we still
  have XUL dependencies that we need to get rid of first and that work is
  independent from moving the code to a top-level devtools/ directory.

 We don't use XUL, but we can still open XUL windows.
 Would it be possible to use the devtools without chrome://browser/
 being accessible?


I doubt it, although, to be honest, I am not entirely sure. We already use
paths like chrome://browser/content/devtools/debugger.xul in the code, so
they would have to be changed first. Would using resource: URLs work better
for browser.html?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: Moving DevTools to top level /devtools directory

[Panos Astithas]

If you are thinking about shipping them as part of browser.html, we still
have XUL dependencies that we need to get rid of first and that work is
independent from moving the code to a top-level devtools/ directory.

On Wed, Jul 22, 2015 at 1:48 PM, Paul Rouget p...@mozilla.com wrote:

 Does that include getting rid of /browser/ dependencies?
 Ideally, we'd like to be able to compile non-Firefox builds with our
 devtools.

 On Tue, Jul 21, 2015 at 11:54 PM, J. Ryan Stinnett jry...@gmail.com
 wrote:
  The DevTools team is planning to move our code out of
  /browser/devtools and /toolkit/devtools and into a new top level
  /devtools directory.
 
  The main goals of this are to reduce confusion for new DevTools
  contributors and help us better organize our work in the future. It
  will also aid future users of the code in understanding what pieces
  they need to include.
 
  There should be no impact to DevTools features shipped in different
  products: Firefox desktop will continue to be the only product that
  ships the DevTools front end, and all others will ship the DevTools
  server only.
 
  It is my understanding that the DevTools team received approval for a
  new top level directory from Brendan several years ago.
 
  Bug: https://bugzil.la/912121
 
  (Replies to dev-platform.)
 
  - Ryan
  ___
  dev-developer-tools mailing list
  dev-developer-to...@lists.mozilla.org
  https://lists.mozilla.org/listinfo/dev-developer-tools



 --
 Paul
 ___
 dev-developer-tools mailing list
 dev-developer-to...@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-developer-tools

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

Re: Changing the style guide's preference for loose over strict equality checks in non-test code

[Panos Astithas]

On Thu, May 14, 2015 at 11:22 PM, Gijs Kruitbosch gijskruitbo...@gmail.com
wrote:

 My point is there will be just as many unexpected issues when you use
 === on opaque variables, because you didn't expect that that code in that
 other file set this thing to null instead of deleting the property (causing
 it to not be === undefined in your comparison) -- for example.


This. From the perspective of a library method validating inputs, I've
always found it pays off to rely on Postel's principle.

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

Re: mochitest-chrome tests now running on B2G emulators

[Panos Astithas]

This is very cool, I've been waiting for this for a long time!

I see that existing tests are now skipped by default on b2g, e.g.:

https://dxr.mozilla.org/mozilla-central/source/toolkit/devtools/server/tests/mochitest/chrome.ini#2

Is this because nobody has tested whether they work yet, or is it because
they are not working on b2g as they are written? If the latter, do you have
any insights on what needs to change?

Thanks,
Panos


On Tue, Mar 24, 2015 at 1:38 AM, Jonathan Griffin jgrif...@mozilla.com
wrote:

 A mochitest-chrome job is now running on B2G emulators, and appears in
 Treeherder as M(c).  This job skips most existing chrome tests, since most
 of the existing tests are not compatible with B2G.  But it provides a
 better alternative when writing mochitests that need chrome privileges than
 using SpecialPowers in mochitest-plain.

 If you want your new chrome mochitest to get run on B2G, just make sure
 it's written as an XHTML file and not a XUL one; see

 https://dxr.mozilla.org/mozilla-central/source/testing/mochitest/static/chrome.template.txt
 .

 If you don't want your new chrome mochitest to run on B2G, just add
 skip-if = buildapp == 'b2g' to the relevant chrome.ini manifest.

 To run the tests locally, just add a --chrome argument to your
 runtestsb2g.py command-line, as documented here:

 https://developer.mozilla.org/en-US/Firefox_OS/Platform/Automated_testing/Mochitests#Running_the_tests_2

 Regards,

 Jonathan
 ___
 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: mochitest-chrome tests now running on B2G emulators

[Panos Astithas]

On Tue, Mar 24, 2015 at 6:40 PM, Jonathan Griffin jgrif...@mozilla.com
wrote:

 Most (or all) of the tests in that directory were not working on B2G as
 written.   They were timing out and causing the harness to abort.  So I
 disabled that entire directory in the interests of getting the job running.

 I haven't debugged any of those, but you could remove that line from the
 manifest and run them on try with the syntax:

 -b o -p emulator -u mochitest-chrome -t none



Thanks, filed bug 1147001.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Is it time for mochitest-chrome on Android and B2G

[Panos Astithas]

Support for mochitest-chrome on mobile is sorely needed in devtools. It
would increase our test coverage there by at least an order of magnitude.

Panos


On Wed, Jun 18, 2014 at 2:48 AM, Bobby Holley bobbyhol...@gmail.com wrote:

 I can't comment on the importance of the a-team's other priorities, or the
 importance of running the tests in consideration on Android/B2G.

 However, as the author of SpecialPowers.wrap, I can say that using it for
 highly-involved chrome interaction should be considered Extremely Harmful.
 These wrappers are designed as a convenience mechanism to access the
 occasional privileged or cross-origin property, and have a lot of magic and
 footguns that both (a) waste developer time and (b) reduce the value of our
 test coverage (because it often isn't testing what the author thought it
 was testing).

 One middle-ground here is SpecialPowers.loadChromeScript(uri), which allows
 arbitrary chrome scripts to be run (in their entirety) via the message
 manager. I consider that to be a robust and valid approach, but I don't
 have a good sense of whether the ergonomics there are acceptable for the
 use-cases in question.

  In general though, it seems like it would be pretty great if newly-added
 mochitest-chrome tests would automatically run on B2G and Android if we
 want those to be first class platforms. I myself write mochitest-chrome
 tests all the time, and there's no reason that most of those couldn't also
 run on mobile.

 bholley


 On Tue, Jun 17, 2014 at 4:32 PM, Jonathan Griffin jgrif...@mozilla.com
 wrote:

  Periodically, we field a request to add support for mochitest-chrome to
  Android and B2G.  To date, we've avoided this by pointing out ways that
  mochitest-plain can be used for the same use case, which usually involves
  SpecialPowers.
 
  We have a new request for this, in the context of requestAutocomplete (
  https://bugzilla.mozilla.org/show_bug.cgi?id=1021060#c16).  The tests
 for
  this, as well as some other features we've seen requests for, need to be
  able to execute some setup code with chrome privileges, and SpecialPowers
  isn't always flexible enough.  As bholley points out, SpecialPowers is a
  best effort and doesn't necessarily support everything a test may wish
 to
  do.
 
  Has the time come to bite the bullet and add mochitest-chrome support to
  Android and B2G?  This would be a non-trivial effort, and would need to
 be
  done separately for Android and B2G.  Adding support for this would come
 at
  the expense of something else, possibly work related to Android 4.4 tests
  on emulators, work integrating our harnesses with structured logging,
  and/or work on reducing our intermittent test failures on B2G.  These
 tasks
  are important and I wouldn't want to delay them without a very clear
 need.
   Does that exist here?
 
  Note that we are talking only about enabling harness support for
  mochitest-chrome in Android and B2G in order to provide a framework for
  tests that would otherwise be difficult to write.  We are not talking
 about
  taking the existing set of mochitest-chrome tests and getting them to
 work
  in Android and B2G.  Many of those tests don't apply to Android or B2G,
 and
  for those that theoretically do, many of them won't work because they
 rely
  on XUL files which aren't supported in B2G, and may not be in Android
 (not
  sure on that point).
 
  For more context about the history of mochitest-chrome on B2G, see
  https://bugzilla.mozilla.org/show_bug.cgi?id=797164
 
  Jonathan
 
  ___
  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

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

Re: Web Replay

[Panos Astithas]

On Wed, Jan 15, 2014 at 10:24 AM, Dirkjan Ochtman dirk...@ochtman.nlwrote:

 This may be a stupid question, but I just saw this on the webkit
 mailing list: a way to capture network/user input events (with
 negligible overhead) for debugging purposes.

 https://lists.webkit.org/pipermail/webkit-dev/2014-January/026062.html

 I didn't find any bugs about this; it seems interesting, though.


There is bug 738965, which discusses a subset of this, but nobody has plans
to work on it AFAIK. We even had Jake Bailey as an intern last summer who
has worked on timelapse with Brian Burg, but he worked on a tracer for
Firefox, not timelapse.

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

Re: Should we disable autoplay feature of HTMLMediaElement on mobile?

[Panos Astithas]

On Mon, Dec 9, 2013 at 4:48 PM, Gervase Markham g...@mozilla.org wrote:

 On 08/12/13 12:28, Tetsuharu OHZEKI wrote:
  On today's web, there are many interactive web sites which play
  sounds when open them.

 I suspect this is somewhat dependent on your culture and environment;
 it's not a problem on the set of websites I visit :-)

  Some of them are not controlled by users
  because they doesn't not provide any control.

 If a website played music at me with no way to turn it off, I'd probably
 leave and never come back...

 Personally, also, it makes it easier for people to hide their porn use
 from others is not an argument which gets much traction with me.


I don't know about that use case, but mine involves Spotify and Soundcloud,
which I have pinned as app tabs. Every now and then I will close the
browser before shutting down the laptop, without remembering to pause the
music in one of those tabs. Booting the laptop afterwards in a public place
never fails to annoy some people.

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