Re: Using the accesskey attribute with HTML elements in browser chrome

2017-06-20 Thread Ehsan Akhgari 

On 06/20/2017 04:36 PM, Brian Grinstead wrote:

On Jun 19, 2017, at 6:58 PM, Ehsan Akhgari  wrote:

On 06/19/2017 04:28 PM, Brian Grinstead wrote:

I was wondering what would need to be done in order to use the accesskey 
attribute on HTML elements in the browser chrome. Here are some of the 
differences between the attribute in HTML and XUL that I've found so far:

1) In XUL 
(https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/Attribute/accesskey) 
the shortcut is `Control + key` on Windows and `Command + key` on Mac. In HTML 
(https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/accesskey) 
the shortcut is `Alt + Shift + key` on Windows and `Control + Alt + key` on 
Mac. Would we want to change the HTML shortcut (in browser chrome) to match XUL 
behavior?

As far as I can tell this was last changed/discussed in 
https://bugzilla.mozilla.org/show_bug.cgi?id=340902, and Mats may be the right 
person to comment on it (but do note that this hasn't changed since Firefox 2.)


2) The FAQ & Policies page 
(https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/XUL_Accesskey_FAQ_and_Policies)
 conflicts the with previous point when it says that accesskey is only available on 
Mac in HTML. If this is correct, would we want to disable accesskey functionality 
on Mac for HTML (in browser chrome) to maintain the current behavior, or would it 
working be a benefit of using HTML?

That documentation seems incorrect.  Mac 

 uses different defaults than other OSes 
.
 Not sure why.  :-)

3) The formatting / underlining is controlled by the label-control xbl binding 
at 
http://searchfox.org/mozilla-central/source/toolkit/content/widgets/text.xml#66.
 Presumably this is something that would need to be reimplemented for HTML 
elements in order to use them in the browser chrome.

The underlining?  Could that not be achieved using CSS?

It’s a little too complicated for CSS alone. The code in xbl splits up the 
element so that it can underline the first instance of the character only.  And 
if it can’t find the character than it appends at the end of the label in 
parenthesis while doing some extra special casing if the label ends in a colon.

Oh, right.  Fair enough.

on Windows, the OS native widgets have a custom way of handling the underlining 
IIRC to draw it only when Alt is pressed or something along those lines and at 
some point we also had a bug about it to implement it for XUL, but I'm not sure 
if we ever did that and I can't find the bug right now, but something to double 
check perhaps.


Thanks for the info, I didn’t realize that. I did some looking around and found 
https://bugzilla.mozilla.org/show_bug.cgi?id=25894 which I think is what you 
are referring to. Although apparently that system setting is off by default as 
of Windows 7.
Yes!  This is what my vague memory was about.  I suppose it doesn't 
matter that much in practice.  :-)

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

Re: Intent to unship: HTML scoped style sheets (

2017-06-20 Thread Cameron McCormack 
On Wed, Jun 21, 2017, at 02:05 AM, Bobby Holley wrote:
> Yeah - stylo for the frontend would be nice, but it's not part of
> our MVP.
Thanks for confirming what I thought was the case. :-)

On Tue, Jun 20, 2017, at 03:26 PM, Patrick Brosset wrote:
> Cameron, what bug should this one block (iiuc chrome support will be
> removed a bit later, so we have some time, do you already have a bug
> for that part?)
I'm using https://bugzilla.mozilla.org/show_bug.cgi?id=1345702 for the
removal of

Re: Changing .idl files

2017-06-20 Thread Nicholas Nethercote 
I just found https://bugzilla.mozilla.org/show_bug.cgi?id=1347507: "Stuff
we can remove when XPCOM extensions are no longer supported". A number of
the blocking bugs are for removing XPIDL interfaces. If you know of other
things that can be removed, please add them as blocking bugs.

Nick

On Wed, Jun 14, 2017 at 10:40 AM, Nicholas Nethercote <
n.netherc...@gmail.com> wrote:

> Hi,
>
> What must be considered when changing an XPIDL interface in a .idl file?
> As far
> as I know, it's the following.
>
> (1) Update browser C++ code that uses the interface. This is easy because
> the
> compiler will tell you the parts that need changing.
>
> (2) Update browser JS code that uses the interface. This is harder because
> it
> requires using grep or a similar tool to find all the occurrences. But it's
> usually not too bad.
>
> (3) Do extensions use it? If so, changing it probably isn't possible. This
> can
> be imperfectly determined by searching through addons/ in DXR.
>
> (4) Does Thunderbird use it? This is no longer a hard constraint, but is
> something to consider.
>
> Once Firefox 57 disallows all extensions other than Web Extension, I think
> (3) will
> no longer be relevant. In which case, once 57 is under development (August
> ~7th)
> it will be *much* easier to change XPIDL interfaces.
>
> (Although, if DevTools are moved its their own repository, that repo will
> have to be
> checked as well?)
>
> Is all that correct? Have I missed anything? Thanks.
>
> Nick
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to unship: Add-on SDK and others

2017-06-20 Thread Andrew McKay 
With Firefox 57 only running WebExtensions, we are hoping to spend
some time *after* Firefox 57 doing some cleaning and removing
un-needed code. The plans are still being formed, but we are aiming to
land some of these in the Firefox 58 or Firefox 59 trains. The
timetable is currently under discussion. The three main areas are:

* Removing the Add-on SDK. By Firefox 57 there should be no add-ons
(from within Mozilla or external) using the SDK on release.
https://bugzilla.mozilla.org/show_bug.cgi?id=1371065

* Removing support for un-supported configurations from Add-ons
Manager. https://bugzilla.mozilla.org/show_bug.cgi?id=1371064

* Removing some XPCOM support. There is no requirement from add-ons
team to keep XPCOM support around for experiments.
https://bugzilla.mozilla.org/show_bug.cgi?id=1347507

There will probably be more, but these are the three main areas. If
you have any questions or concerns, please comment on the bugs or
reach our to the team: https://wiki.mozilla.org/Add-ons#Who
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Profiling nightlies on Mac - what tools are used?

2017-06-20 Thread Gregory Szorc 
On Tue, Jun 20, 2017 at 10:28 AM, Ehsan Akhgari 
wrote:

> On 06/20/2017 12:28 PM, Nathan Froyd wrote:
>
>> On Tue, Jun 20, 2017 at 12:19 PM, Ehsan Akhgari 
>> wrote:
>>
>>> On 06/20/2017 08:34 AM, Nathan Froyd wrote:
>>>
 There is some kind of interaction with the underlying machine (see
 comment 104 in said bug, where the binaries perform identically on a
 local machine, but differently on infrastructure), but we haven't
 tracked that down yet.

>>>  From comment 104 it seems that it is possible to reproduce the slowdown
>>> from
>>> the unstripped cross builds locally.  Has anyone profiled one of these
>>> builds comparing them to an unstripped non-cross build to see where the
>>> additional time is being spent?  I couldn't tell from the bug if this
>>> investigation has happened.
>>>
>> My understanding is that the slowdown cannot be reproduced on local
>> developer machines, but can be reproduced on loaner machines from
>> infra.
>>
> Huh.  That's interesting and even more puzzling...
>
>> I don't think anybody has tried profiling on infra to see
>> where time differences are.
>>
> That seems like the obvious next step to investigate to me.  We should
> *really* only talk about stripping builds as the last resort IMO, since we
> have way too many developers using OSX every day...
>

I would argue it is in our best interest to have as little divergence
between Firefox release channels as possible. Today, Nightly is distributed
with symbols and Beta/Release/ESR all ship without symbols. There are other
variations between the build configurations as well. Every variation
between channels increases the risk of introducing bugs or other undesired
behavior and that said behavior won't be detected until weeks after it has
landed on central (we can run CI for these variations, sure, but that's no
substitute for a user base). It should not be a controversial statement to
say that variation between build configurations / channels is not ideal.

In the case of debug symbols, we've historically made the trade-off that
symbols are useful to developers using Nightly, they don't appear to have a
significant downside (other than package/download size), so why not ship
them. We've accepted the risk of this variation in the Nightly channel in
return for not inconveniencing developers. What's happening now is that we
have a new problem caused by debug symbols for cross builds and we are
re-assessing whether the trade-off to ship debug symbols on Nightly is
still justified. If it is, then there may be considerable work to preserve
the status quo. I understand stripping Nightly would be inconvenient and I
personally don't want to do it for this reason. But the flip side is we
converge the configurations for Nightly and Beta, which I argue is a good
thing.

FWIW, I'd like to point out that Chrome Canary (Nightly equivalent) doesn't
ship debug symbols for MacOS (assuming my methodology of running `nm
--debug-syms` is correct). While this is quite possibly due to Chrome
having closed source components, their developers have obviously found a
way to work without debug symbols on shipped builds. I'd like to think that
if Chrome has figured out how to make it work, we can too.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Profiling nightlies on Mac - what tools are used?

2017-06-20 Thread Jeff Muizelaar 
Very much so yes. Even if having unstripped builds were universally
slower (they only seem to be only slower on the ci machines) any
performance impact is likely to not impact the distribution of samples
substantially.

On Tue, Jun 20, 2017 at 2:09 PM, Chris Peterson  wrote:
> On 6/20/17 10:28 AM, Ehsan Akhgari wrote:
>>
>> That seems like the obvious next step to investigate to me.  We should
>> *really* only talk about stripping builds as the last resort IMO, since we
>> have way too many developers using OSX every day...
>
>
> Does profiling an unstripped Mac build still produce useful results if the
> unstripped builds are slower than the stripped builds we ship to users?
>
> ___
> 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: Getting a JS stack from an automation assertion

2017-06-20 Thread Boris Zbarsky 

On 6/20/17 1:53 PM, Benjamin Smedberg wrote:

Is there a way to have automation call DumpJSStack() on assertion (before
crashing)


You could hack a DumpJSStack() call into the nsDebug machinery, basically.


Would it be safe to call DumpJSStack() explicitly from the place where I'm
firing this assertion, or are there potential issues with locking or the JS
engine internals that would make this a bad idea? (And would that output
show up in the automation logs?)


Calling DumpJSStack is generally safe, I believe, as long as you know 
that you're on the main thread or a DOM worker thread.  It'll crash on 
you on other threads.


Given that you're dealing with shutdown, you need to make sue your call 
happens before nsContentUtils::Shutdown, but hopefully that's the case 
anyway if you know you're running JS.


One possible failure mode of DumpJSStack is that it will print nothing 
if we're conceptually not running JS (e.g. have an AutoNoJSAPI on the 
stack).  You could work around that if you end up hitting it by 
replacing the nsContentUtils::GetCurrentJSContextForThread() call in 
xpc_DumpJSStack with mozilla::dom::danger::GetJSContext.


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

Re: Intent to unship: HTML scoped style sheets (

2017-06-20 Thread Bobby Holley 
Yeah - stylo for the frontend would be nice, but it's not part of our MVP.

It wouldn't be hard, just presumably implementing a few more scattered
internal things and fixing more bugs exposed by the heavier usage of XBL.
But we could ship in 57 without it, and so it seems foolish to widen our
scope before driving our existing blockers to zero. If everything else is
done early, we can see whether we want to try for stylo-chrome in 57 as
well.

On Tue, Jun 20, 2017 at 10:56 AM, Chris Peterson 
wrote:

>
>
> On 6/20/17 2:14 AM, Cameron McCormack wrote:
>
>> Cameron, what bug should this one block (iiuc chrome support will be
>>> removed a bit later, so we have some time, do you already have a bug for
>>> that part?)
>>>
>>
>> Actually, let me backtrack a little.  I might be misremembering our plans
>> for Stylo in chrome documents.  Chris or Bobby, can you remind me whether
>> we are still planning to target chrome documents?
>>
>> If we are, then it makes it a little more urgent to remove current usages
>> of

Re: Intent to unship: HTML scoped style sheets (

2017-06-20 Thread Chris Peterson 



On 6/20/17 2:14 AM, Cameron McCormack wrote:
Cameron, what bug should this one block (iiuc chrome support will be 
removed a bit later, so we have some time, do you already have a bug 
for that part?)


Actually, let me backtrack a little.  I might be misremembering our 
plans for Stylo in chrome documents.  Chris or Bobby, can you remind 
me whether we are still planning to target chrome documents?


If we are, then it makes it a little more urgent to remove current 
usages of

Re: Errors found by cppcheck

2017-06-20 Thread Andrew Halberstadt 
Yes, we can blacklist checks with:
cppcheck --suppress=

You can see the check ids with:
cppcheck --errorlist

It's actually even more flexible, checks can be disabled for specific
files, directories and even lines in the file. And it can all be specified
in a text file then passed in with:
cppcheck --suppressions-list=

Maybe we could start off running this as tier 3 (so it won't cause
backouts, but people who care can check up on it once in awhile). We could
modify the list of checks to exclude over time and maybe get a better sense
of whether or not the job is catching anything useful.

On Sun, Jun 18, 2017 at 3:08 PM, Ehsan Akhgari 
wrote:

> Is it possible to run cppcheck in a mode where we select which checks it
> runs?  If yes, we could look at the list of true positives that people have
> found (and continue to find) in bug 1370292 and create an opt-in set of
> checks that rare valuable ones to have turned on by default, and leave the
> rest off by default. (I'm hoping the effectiveness of its check isn't
> context sensitive...)
>
>
>
> On 06/06/2017 09:06 AM, Andrew Halberstadt wrote:
>
>> I was doing a bit of research into cppcheck [1] to see if it might be
>> worth
>> running as a linter (alongside eslint, flake8 etc). More discussion in bug
>> 1370292 [2]. I ran it against the entire tree [3] and got these results:
>> https://bug1370292.bmoattachments.org/attachment.cgi?id=8874498
>>
>> So far it looks like the false positive rate is too high to warrant
>> standing up a job in CI. It seems it would cause more frustration than
>> it's
>> worth. But there are likely some legit errors in there, so please take a
>> quick look to see if any apply to your module. Feel free to comment over
>> in
>> bug 1370292 if you have opinions one way or the other on standing this up
>> as a task. Barring a claim that it would be useful, I'll be WONTFIXing
>> that
>> bug in a bit.
>>
>> -Andrew
>>
>>
>> [1] http://cppcheck.sourceforge.net/
>> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1370292
>> [3] cppcheck $(sed -e 's/^/-i/' tools/rewriting/ThirdPartyPaths.txt)
>> -ithird_party . 2> errors.txt
>> ___
>> 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: Profiling nightlies on Mac - what tools are used?

2017-06-20 Thread Nathan Froyd 
On Tue, Jun 20, 2017 at 12:19 PM, Ehsan Akhgari  wrote:
> On 06/20/2017 08:34 AM, Nathan Froyd wrote:
>> There is some kind of interaction with the underlying machine (see
>> comment 104 in said bug, where the binaries perform identically on a
>> local machine, but differently on infrastructure), but we haven't
>> tracked that down yet.
>
> From comment 104 it seems that it is possible to reproduce the slowdown from
> the unstripped cross builds locally.  Has anyone profiled one of these
> builds comparing them to an unstripped non-cross build to see where the
> additional time is being spent?  I couldn't tell from the bug if this
> investigation has happened.

My understanding is that the slowdown cannot be reproduced on local
developer machines, but can be reproduced on loaner machines from
infra.  I don't think anybody has tried profiling on infra to see
where time differences are.

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

Recording code loaded during startup, and avoiding regressions

2017-06-20 Thread Florian Quèze 
As part of Quantum/Photon, we are working on improving startup
. More specifically,
we care a lot about reducing the time it takes to first paint the browser
window. Sometimes this means removing useless code
, but more often it
means delaying initialization of some components until after first paint.
Following this approach, we already delayed initialization of Places (1
, 2
), NSS (1
, 2
, 3
, 4
), Task.jsm (1
, 2
), and the search
service (1 , 2
). These things are
easy to regress, so I decided to add test coverage to prevent future
accidents (we actually saw things loaded during early startup only by
accident ).

We now have a test checking what gets loaded during startup.
This works by having an XPCOM component (startupRecorder.js
)
loaded early during startup that fetches the list of loaded JS modules and
components  and the
list of instantiated services
 at various phases of
startup. (Note: this component only exists on Nightly and debug builds, to
avoid overhead for release users).
We then have a browser chrome test (browser_startup.js
)
that gets the data from startupRecorder.js, and compares it with whitelists
and blacklists. Eventually we want to review everything that gets loaded
during startup, and whitelist only the modules that have a valid reason to
be loaded before first paint. Currently we have only done it for code
loaded at app-startup ,
and we have blacklists for code loaded during later stages of startup.

Here is where I would like your help:

- please don't add anything to the whitelists in browser_startup.js without
asking me (or someone else working on photon-performance) for review; our
whitelists should shrink, not grow.

- when you successfully delay initialization of some code during startup,
consider adding test coverage to ensure it won't regress. Blacklisting
something is a simple one line addition to browser_startup.js

- please have a quick look at the list of what's currently loaded. If you
see some low hanging fruits there, or some code that you own that gets
loaded too early, please file a bug to get it fixed (feel free to cc me on
it). As a rule of thumb, anything that doesn't impact the appearance of the
browser window at first paint shouldn't be loaded before first paint.
You can see this list by running ./mach test
browser/base/content/test/performance/browser_startup.js on your local
build.
For convenience, I'm including at the end of this message the current list
the test outputs on Windows.

Looking forward to a faster than ever Firefox 57!

Thanks,
Florian


components loaded before profile selection: WebContentConverter.js
components loaded before profile selection: nsBrowserGlue.js
components loaded before profile selection: MainProcessSingleton.js
components loaded before profile selection: nsSessionStartup.js
components loaded before profile selection: PushComponents.js
modules loaded before profile selection: resource://gre/modules/Services.jsm
modules loaded before profile selection:
resource://gre/modules/XPCOMUtils.jsm
modules loaded before profile selection:
resource://gre/modules/AsyncPrefs.jsm
modules loaded before profile selection:
resource://gre/modules/RemotePageManager.jsm
modules loaded before profile selection:
resource://gre/modules/AppConstants.jsm
modules loaded before profile selection: resource://gre/modules/Promise.jsm
services loaded before profile selection: @mozilla.org/xre/runtime;1
services loaded before profile selection: @mozilla.org/docloaderservice;1
services loaded before profile selection: @
mozilla.org/spellcheck/dir-provider;1
services loaded before profile selection: @
mozilla.org/test/startuprecorder;1
services loaded before profile selection: @
mozilla.org/layout/content-policy;1
services loaded before profile selection: @mozilla.org/rdf/container-utils;1
services loaded before profile selection: @

Intent to ship: Enable throttling of tracking timeouts on nightly

2017-06-20 Thread Andreas Farre 
Hi all!

As of 2017-06-21 I intend to, for nightly only, turn on throttling of
timeouts from tracking scripts for windows in the foreground. We're
already shipping this for background timeouts, and our hope is that
enabling throttling for foreground will help us determine the
effectiveness of the throttling and also help us find any further
issues with the feature.

The bugs related are: Bug 1372951 and Bug 1355311
This has been discussed previously:
https://groups.google.com/forum/#!searchin/mozilla.dev.platform/throttle$20tracking%7Csort:relevance/mozilla.dev.platform/wu0L6SCeLcc/KiXrawJ3AQAJ

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

Re: Profiling nightlies on Mac - what tools are used?

2017-06-20 Thread Nathan Froyd 
On Tue, Jun 20, 2017 at 3:59 AM, Julian Seward  wrote:
> On 20/06/17 05:58, Boris Zbarsky wrote:
>> On 6/19/17 11:22 PM, Gregory Szorc wrote:
>>> The decision to strip Nightly builds does not come lightly. Read 1338651
>>> comment 111 and later for the ugly backstory.
>>
>> It's still really confusing to me that not stripping symbols has a 
>> significant
>> performance impact.  That's not the case in any other build configuration I'm
>> aware of, and is somewhat surprising from first principles for everything
>> except startup performance.
>>
>> It really would be good to figure out what's actually going on there...
>
> I agree.  Stripping the symbols as a solution makes no sense to me, given
> that they are not expected to be loaded into the process image.
>
> From my scan of 1338651 it appears that we've demonstrated that the same
> preprocessed source is compiled in both cases.  But IIUC (and correct me if
> I'm wrong), we haven't shown that either the same code is generated, nor
> that there is not some different interaction with the underlying machine
> for the two builds.

We have demonstrated that the command lines for linking are basically
identical; there are of course differences in paths.  The native Mac
build was passing a static libc++ archive for linking on the command
line, but we showed that didn't matter by passing the same archive in
the cross-compiled case, which produced no change.

We have looked at the underlying machine code.  It is functionally
identical; jump tables are tagged as data-in-code in one, and there
are some small offset differences in jump instructions (which are due
to slightly different offsets in the binaries themselves), but nothing
else.

We have looked at the binaries themselves (e.g. sections and so
forth).  They are functionally identical; there are some small
differences between them which I think amount to path differences
being baked into the binary.

The native builds are codesigned while the cross ones are not.  This
too makes no difference.

There is some kind of interaction with the underlying machine (see
comment 104 in said bug, where the binaries perform identically on a
local machine, but differently on infrastructure), but we haven't
tracked that down yet.

Your theories are most welcome at this point. :)

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

Re: Profiling nightlies on Mac - what tools are used?

2017-06-20 Thread Ted Mielczarek 
On Tue, Jun 20, 2017, at 03:59 AM, Julian Seward wrote:
> I've used VTune on Linux and have some idea what it can and can't do.
> I have tried it on Mac, but my impression, from the Intel web site, is
> that it is at least available for Mac.

Apparently the version for Mac is just a GUI for viewing results, per[1]
"An optional OS X host interface can be downloaded separately to analyze
data collected on other targets. An OS X collector to profile on OS X is
not currently available."

-Ted

1. https://software.intel.com/en-us/intel-vtune-amplifier-xe
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Using the accesskey attribute with HTML elements in browser chrome

2017-06-20 Thread Masayuki Nakano 

On 6/20/2017 5:28 AM, Brian Grinstead wrote:

I was wondering what would need to be done in order to use the accesskey 
attribute on HTML elements in the browser chrome. Here are some of the 
differences between the attribute in HTML and XUL that I've found so far:

1) In XUL 
(https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/Attribute/accesskey) 
the shortcut is `Control + key` on Windows and `Command + key` on Mac.


Wow, the document is wrong. Ctrl+foo or Cmd+foo are usually called as 
"shortcut key" which are different from "access key".


On Windows, chrome's access key works with Alt.


In HTML 
(https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/accesskey) 
the shortcut is `Alt + Shift + key` on Windows and `Control + Alt + key` on Mac.


Yes, this is right.


Would we want to change the HTML shortcut (in browser chrome) to match XUL 
behavior?


So, I'm not sure if you are talking about access key or shortcut key 
here. But I guess, you're talking about access key.


Then, it depends on the type of DocShell (chrome vs. content). So, not 
related to the file type. E.g., we have this bug: https://bugzil.la/349943



2) The FAQ & Policies page 
(https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/XUL_Accesskey_FAQ_and_Policies)
 conflicts the with previous point when it says that accesskey is only available on 
Mac in HTML. If this is correct, would we want to disable accesskey functionality 
on Mac for HTML (in browser chrome) to maintain the current behavior, or would it 
working be a benefit of using HTML?


On macOS, native UI doesn't have access key. Therefore, we don't support 
it only on macOS.



3) The formatting / underlining is controlled by the label-control xbl binding 
at 
http://searchfox.org/mozilla-central/source/toolkit/content/widgets/text.xml#66.
 Presumably this is something that would need to be reimplemented for HTML 
elements in order to use them in the browser chrome.


Yes. Underlining access key's character needs additional hack. I have no 
idea how to implement it easily in HTML. Perhaps, capsuling with Shadow DOM?


--
Masayuki Nakano 
Software Engineer, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Profiling nightlies on Mac - what tools are used?

2017-06-20 Thread Julian Seward 
On 20/06/17 05:58, Boris Zbarsky wrote:
> On 6/19/17 11:22 PM, Gregory Szorc wrote:
>> The decision to strip Nightly builds does not come lightly. Read 1338651
>> comment 111 and later for the ugly backstory.
> 
> It's still really confusing to me that not stripping symbols has a significant
> performance impact.  That's not the case in any other build configuration I'm
> aware of, and is somewhat surprising from first principles for everything
> except startup performance.
> 
> It really would be good to figure out what's actually going on there...

I agree.  Stripping the symbols as a solution makes no sense to me, given
that they are not expected to be loaded into the process image.

>From my scan of 1338651 it appears that we've demonstrated that the same
preprocessed source is compiled in both cases.  But IIUC (and correct me if
I'm wrong), we haven't shown that either the same code is generated, nor
that there is not some different interaction with the underlying machine
for the two builds.

One thing we could do is profile both with VTune, to look at both

* mispredicts, cache misses (D and I), alignment stalls, whatever .. in
  short, anything that affects IPC.

* average instruction counts for some "known" hot functions, which we can
  reliably compare between builds.  That might show cases where the
  compiler didn't generate identical code.

I've used VTune on Linux and have some idea what it can and can't do.
I have tried it on Mac, but my impression, from the Intel web site, is
that it is at least available for Mac.

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

Re: Intent to unship: HTML scoped style sheets (

2017-06-20 Thread Patrick Brosset 
DevTools also uses a scoped stylesheet in its tooltip widget [1].
I have filed a bug [2] to remove it.

Cameron, what bug should this one block (iiuc chrome support will be
removed a bit later, so we have some time, do you already have a bug for
that part?)

Thanks!
Patrick

[1]
http://searchfox.org/mozilla-central/source/devtools/client/shared/widgets/tooltip/HTMLTooltip.js#643
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1374555

On Tue, Jun 20, 2017 at 7:20 AM, Cameron McCormack  wrote:

> On Tue, Jun 20, 2017, at 01:08 PM, Jared Wein wrote:
> > We use a scoped stylesheet for styling the popup for  [1]. We
> > chose this route to limit performance impact as well as limit our
> > temporary stylesheet from affecting other parts of the browser UI.
> > Will your removal also remove support in the chrome/parent process?
> For now we'll keep  available in chrome documents.  But in
> the medium term , we will want to style chrome documents with Servo too
> https://bugzilla.mozilla.org/show_bug.cgi?id=1294570, and at that point
> we'll have to remove