Re: Should cheddar-generated headers be checked in?

[Henri Sivonen]

On Wed, Feb 22, 2017 at 5:49 PM, Ted Mielczarek  wrote:
> Given that
> the C API here is under your complete control, it seems like it's
> possible to generate a cross-platform header

I believe the header is cross-platform, yes.

> Alternately you could just generate it at build time, and we could pass
> the path to $(DIST)/include in a special environment variable so you
> could put the header in the right place.

So just https://doc.rust-lang.org/std/env/fn.var.html in build.rs? Any
naming conventions for the special variable? (I'm inferring from the
way you said it that DIST itself isn't being passed to the build.rs
process. Right?)

-- 
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Embeddable Browser

[Myk Melez]

Rodolpho Porto 
2017 February 22 at 03:13

Hello Myk Melez,

First of all, thank you for your response!

I'll talk about the project, it's a kiosk-style browser, using 
XULRunner 24.0b10 32bit and SWT, the modifications we made were 
according to project needs and security requirements. All of this is 
in the testing phase, but the project is still evolving, the project 
is huge and XulRunner's share is small but of paramount importance.
If your project is a XUL app, then you should be able to compile Firefox 
with the modifications you made to XULRunner and then use Firefox in 
place of the XULRunner runtime to run the app via Firefox's --app 
command-line flag.


But from your description, I wonder if it's actually a native app that 
you're linking against libxul from the XULRunner SDK. Is that correct? 
And is your code open source and available for browsing online by any 
chance?


-myk

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

ANN: Finally changing the default bug view for BMO on March 1st, 2017

[David Lawrence]

tl;dr

   On March 1st, 2017, the BMO Team is going to make another attempt at
changing the default bug view to the new modal view that has been in
development for a while. For those who would like to use the old form,
instructions on how to switch back are below in the background
information. The old form will however be removed one day so please try
to use the new one and make suggestions on how it can be improved.

Thanks!

Background:

As some of you may already know, and maybe even have been using it
for a while, the BMO [1] team has been working on a new bug view page
(a.k.a show_bug.cgi) for some time [2] . The older, stock bug form was
not well laid out and was difficult to understand, with all of the
fields visible regardless of how often they were used. The stock form
was originally designed to  display all of a bug’s data, and users had
to adapt their workflows accordingly.. The BMO team designed a
completely new and more efficient view for the workflows of the majority
of BMO users.

The new bug-editing form has been added to BMO alongside the stock
form and can be enabled by toggling a user preference [3]. We have been
incrementally improving it and collecting feedback by those brave enough
to use it early on. The new form is using more modern design practices
and therefore is easier for us to improve and expand on. Any new
enhancements will be done only on the new form going forward. It was
code named ‘Bug Modal’ due to the modular layout of the page. Each
submodule can be collapsed out of view and expanded when needed.

At this time we feel that the form is feature complete and ready to
become the new default bug form for BMO. We have been tracking the final
blockers in a bug report [4], and the last blocker(s) are being wrapped
up this week. We wanted to let everyone know of the coming
changeover in advance so that we can get last-minute feedback. The
older, stock bug view form will still be around, and we will update the
user preference to let users switch back to the old one [3]. In the
future, we will be removing the old form altogether after fixing a few
more bugs [6], and we will make another announcement before doing so.
Removing the old code will make it easier on us from a maintenance
standpoint.

Barring any issues with landing the last blocker(s), we are hoping
to do the changeover on March 1st, 2017. Until then, if this is the
first time you have heard of this new feature,  go ahead and give it a
try. Any bugs, comments, or ideas for improvement of the modal form can
be reported in BMO [5].
Thanks!
BMO Team

[1] https://bugzilla.mozilla.org
[2] https://globau.wordpress.com/2015/03/31/bmo-new-look
[3]
https://bugzilla.mozilla.org/userprefs.cgi?tab=settings#ui_experiments_row
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=1150541
[5]
https://bugzilla.mozilla.org/enter_bug.cgi?product=bugzilla.mozilla.org=User%20Interface:%20Modal
[6] https://bugzilla.mozilla.org/show_bug.cgi?id=1273046


-- 
David Lawrence
d...@mozilla.com
bugzilla.mozilla.org
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to unship: "-moz-table-border-non-zero" pseudo-class outside UA stylesheet

[Xidorn Quan]

Currently this prefixed pseudo-class is accessible everywhere, but it is
actually only used in our UA stylesheet so far.

In bug 1341925 [1], I'd like to restrict this pseudo-class to only be
usable inside UA stylesheet.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1341925

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

Re: Please use Add*VarCache and not Get* when reading pref values in any even possibly warm code paths

[Gijs Kruitbosch]

Kit helpfully pointed out that this got fixed 6 months after I filed the 
referenced bug, when Matt Woodrow ran into it with a different pref - 
https://bugzilla.mozilla.org/show_bug.cgi?id=1267868 . So ignore my 
caveat - pref caches should be working normally now 'even' where the 
cached pref name is a string prefix of another pref name.  :-)


~ Gijs

On 22/02/2017 13:23, smaug wrote:

Huh, that is a horrible bug.


On 02/22/2017 01:42 PM, Gijs Kruitbosch wrote:

Related note: add*varcache uses a pref observer behind the scenes.
Pref observers always prefix-match, and the *varcache implementation
doesn't bother
re-checking whether the pref for which it gets a notification matches
the one you requested a cache for. So if you have prefs "blah.foo" and
"blah.foo.bar", changing blah.foo.bar will write garbage into your
cache for blah.foo.

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

~ Gijs

On 22/02/2017 11:18, smaug wrote:

Hi,

Preferences::GetBool is a slow hashtable lookup and has been showing up
in performance profiles in many places.
Please use Preferences::AddBoolVarCache. Same with other pref types.
Or if the pref needs to be read just once, store the value in some
static variable or so.



-Olli






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

Re: Please use Add*VarCache and not Get* when reading pref values in any even possibly warm code paths

[Kris Maglione]

On Wed, Feb 22, 2017 at 01:18:33PM +0200, smaug wrote:

Preferences::GetBool is a slow hashtable lookup and has been showing up in 
performance profiles in many places.
Please use Preferences::AddBoolVarCache. Same with other pref types.
Or if the pref needs to be read just once, store the value in some static 
variable or so.


And in JS code, you can use XPCOMUtils.defineLazyPreferenceGetter for 
the same reasons, and the same effect.

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

Re: Should cheddar-generated headers be checked in?

[Ralph Giles]

I agree with Ted and Jack. For the specific case of the mp4parse
cheddar header, we currently check that in because it wasn't much
hassle, and cheddar pulled in syntex-syntax as a dependency which
added significantly to the build time. Eventually I want to use
runtime binding generation, for the usual reason that having generated
source code under version control is confusing. Porting cheddar to the
new `syn` crate would address the issue with build time.

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

Re: Intent to implement and ship CSS 'appearance' with '-webkit-appearance' as an alias. Unship '-moz-appearance'.

[Benjamin Smedberg]

On Thu, Feb 16, 2017 at 2:57 PM, L. David Baron  wrote:

> On Thursday 2017-02-16 13:20 -0500, Benjamin Smedberg wrote:
> > I'm surprised and disheartened that "land it and see what breaks" is
> > considered an acceptable strategy for pretty much any commit, but
> > especially for web compat.
>
> I don't think this is a realistic argument.  Basically any change we
> make to Gecko, including implementing new features, can affect Web
> compat.  We have to use judgment about which ones require measuring.
>

I agree that not everything requires measurement. I am saying that we need
a deliberate approach to risk, and that if we primarily relies on our
prerelease users to file bugs, we are not going to have any strong
guarantees of web compatibility.

Agree that this is not just for feature removals: new features may have
little risk if nobody on the web is using them. Or they may be very risky
if Chrome has deployed them and they already have traction, to the point
where web compatibility means implementing bug-for-bug compatibility with
Chrome and altering the specification.

So I want us to approach this from multiple approaches: what kinds of web
crawling automation could help mitigate webcompat risk?  What about
targeted fuzzing?


>
>
> > In this case, I understand the advantage of shipping CSS 'appearance'.
> I'm
> > less sure about what it would cost us to keep supporting -moz-appearance:
> > none, perhaps indefinitely.
>
> The cost is long-term or permanent differences between rendering
> engines, which leads to extra work for Web developers and to
> Web-compatibility problems for us.
>

And yet, that is sometimes (often?) a cost we should be prepared to bear.
The market costs of breaking almost any existing web content is so high
that we cannot afford to do it without knowing, and we should be prepared
to keep our quirks at the cost of extra engineering time and legacy support.

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

Re: Should cheddar-generated headers be checked in?

[Jack Moffitt]

I think running bindgen at build time will be the best practice. That
is certainly what stylo and the spidermonkey bindings are aiming for.
This capability of bindgen is pretty new, so it will take a while
before the Rust community adapts.

jack.

On Wed, Feb 22, 2017 at 8:49 AM, Ted Mielczarek  wrote:
> On Wed, Feb 22, 2017, at 07:11 AM, Henri Sivonen wrote:
>> Looking at mp4parse, the C header is generated:
>> https://searchfox.org/mozilla-central/source/media/libstagefright/binding/mp4parse_capi/build.rs
>> But also checked in:
>> https://searchfox.org/mozilla-central/source/media/libstagefright/binding/include/mp4parse.h
>>
>> Is this the best current practice that I should follow with encoding_rs?
>>
>> See also:
>> https://users.rust-lang.org/t/how-to-retrieve-h-files-from-dependencies-into-top-level-crates-target/9488
>> (unanswered at the moment)
>
> I don't think we have a best practice for this currently. We hit the
> opposite issue with bindgen, and I've been informed that we need to run
> bindgen at build time because the bindings are ABI-specific. Given that
> the C API here is under your complete control, it seems like it's
> possible to generate a cross-platform header that doesn't have those
> issues, so you could certainly check it in. The only question there is
> how much hassle it will be for you to maintain a checked-in copy.
>
> Alternately you could just generate it at build time, and we could pass
> the path to $(DIST)/include in a special environment variable so you
> could put the header in the right place.
>
> -Ted
> ___
> 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: Should cheddar-generated headers be checked in?

[Ted Mielczarek]

On Wed, Feb 22, 2017, at 07:11 AM, Henri Sivonen wrote:
> Looking at mp4parse, the C header is generated:
> https://searchfox.org/mozilla-central/source/media/libstagefright/binding/mp4parse_capi/build.rs
> But also checked in:
> https://searchfox.org/mozilla-central/source/media/libstagefright/binding/include/mp4parse.h
> 
> Is this the best current practice that I should follow with encoding_rs?
> 
> See also:
> https://users.rust-lang.org/t/how-to-retrieve-h-files-from-dependencies-into-top-level-crates-target/9488
> (unanswered at the moment)

I don't think we have a best practice for this currently. We hit the
opposite issue with bindgen, and I've been informed that we need to run
bindgen at build time because the bindings are ABI-specific. Given that
the C API here is under your complete control, it seems like it's
possible to generate a cross-platform header that doesn't have those
issues, so you could certainly check it in. The only question there is
how much hassle it will be for you to maintain a checked-in copy.

Alternately you could just generate it at build time, and we could pass
the path to $(DIST)/include in a special environment variable so you
could put the header in the right place.

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

[Firefox Desktop] Issues found: February 13th to February 17th

[Cornel Ionce]

Hi everyone,

Here's the list of new issues found and filed by the Desktop Release QA 
Team last week, *February 13 - February 17* (week 7).


Additional details on the team's priorities last week, as well as the 
plans for the current week are available at:


   https://public.etherpad-mozilla.org/p/DesktopManualQAWeeklyStatus



*RELEASE CHANNEL*
none

*BETA CHANNEL*

ID  Summary Product Component   Is a regression 
Assigned to
1340545 
Vimeo's recommended titles are clipped
Tech Evangelism
Desktop
	YES 
 
	NOBODY

1340560 
.mp4 videos not played in Firefox on Windows XP
Core
Audio/Video: Playback
NO  NOBODY
1340559 
Seeking videos on XP jumps randomly to specific time-stamps
Core
Audio/Video: Playback
NO  NOBODY


*AURORA CHANNEL*
ID  Summary Product Component   Is a regression 
Assigned to
1339792  	The background changes its color 
when dismissing the color panel 	Core 	Audio/Video: Playback 	NO 	NOBODY

1339830 
	The background color is not changed in real time on Mac 	Core 
Audio/Video: Playback 	NO 	NOBODY

1339839 
	Flickering and bad repainting occur after hitting the "Terminate GPU 
Process" button 	Core 	Graphics

NO  David Anderson 
1339852 
Terminating "Gpu Process" while in PDF presentation mode causes a tab 
crash
Core
GraphicsNO  David Anderson 
1339859 
	Very slow width resize action when multiple tabs are pinned using 
compact themes

Core
Widget: Cocoa
NO  NOBODY
1340131 
Stub installer checkboxes spacing inconsistent
Firefox
Installer
TBD NOBODY
1340206 
	Compact Themes makes text on location bar to look blurry/bouncy when 
hovering with RTL builds

Firefox
Themes
NO  NOBODY
1340173 
Hover feedback for zoom reset button is too tall
Firefox
Themes
	YES 
 
	Dao Gottwald 

1340435 
[Linux] Zoom reset button missing hover feedback
Firefox
Themes
	YES 
 
	NOBODY

1340436 
	[Linux] Clicking on zoom buttons positioned in Toolbar makes it move a 
few pixels to the left

Firefox Themes
	YES 
 
	Dao Gottwald 

1340502 
	Reader Mode icon in URL-bar is not displayed when close the reader mode 
view (on wikipedia)

Toolkit
Reader Mode
	YES 
 
	NOBODY

1340473 
	[Ubuntu] The X button from Developer Toolbar is barely visible with 
Compact Dark theme applied

Firefox
Theme
NO  NOBODY
1340129 
	.ogv videos only working after skipping forward/backwards on the 
progress bar
	Core 	Audio/Video: Playback 	YES 
 
	Jean-Yves Avenard 



*NIGHTLY CHANNEL
*
ID  Summary Product Component   Is a regression 
Assigned to
1339754 
	Compact themes are not applied after restart if you try to enable them 
with a complete theme installed

Toolkit
Add-ons Manager
NO  NOBODY
1340149 
	Video and audio not in sync between Windows 10 and Mac OS X 10.11 using 
appear.in 	Core

WebRTC: Audio/Video
TBD NOBODY
1340553 
	The rulers are not dismiss if using the 'rulers' command in Developer 
Toolbar

Firefox
Developer Tools: Inspector
NO  Mateo Ferretti 

*
ESR CHANNEL*
none


Regards,
Cornel Ionce
Team Lead
Softvision

The content of this 

Re: Please use Add*VarCache and not Get* when reading pref values in any even possibly warm code paths

[smaug]

Huh, that is a horrible bug.


On 02/22/2017 01:42 PM, Gijs Kruitbosch wrote:

Related note: add*varcache uses a pref observer behind the scenes. Pref 
observers always prefix-match, and the *varcache implementation doesn't bother
re-checking whether the pref for which it gets a notification matches the one you 
requested a cache for. So if you have prefs "blah.foo" and
"blah.foo.bar", changing blah.foo.bar will write garbage into your cache for 
blah.foo.

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

~ Gijs

On 22/02/2017 11:18, smaug wrote:

Hi,

Preferences::GetBool is a slow hashtable lookup and has been showing up
in performance profiles in many places.
Please use Preferences::AddBoolVarCache. Same with other pref types.
Or if the pref needs to be read just once, store the value in some
static variable or so.



-Olli




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

Should cheddar-generated headers be checked in?

[Henri Sivonen]

Looking at mp4parse, the C header is generated:
https://searchfox.org/mozilla-central/source/media/libstagefright/binding/mp4parse_capi/build.rs
But also checked in:
https://searchfox.org/mozilla-central/source/media/libstagefright/binding/include/mp4parse.h

Is this the best current practice that I should follow with encoding_rs?

See also:
https://users.rust-lang.org/t/how-to-retrieve-h-files-from-dependencies-into-top-level-crates-target/9488
(unanswered at the moment)

-- 
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Please use Add*VarCache and not Get* when reading pref values in any even possibly warm code paths

[Gijs Kruitbosch]

Related note: add*varcache uses a pref observer behind the scenes. Pref 
observers always prefix-match, and the *varcache implementation doesn't 
bother re-checking whether the pref for which it gets a notification 
matches the one you requested a cache for. So if you have prefs 
"blah.foo" and "blah.foo.bar", changing blah.foo.bar will write garbage 
into your cache for blah.foo.


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

~ Gijs

On 22/02/2017 11:18, smaug wrote:

Hi,

Preferences::GetBool is a slow hashtable lookup and has been showing up
in performance profiles in many places.
Please use Preferences::AddBoolVarCache. Same with other pref types.
Or if the pref needs to be read just once, store the value in some
static variable or so.



-Olli


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

Please use Add*VarCache and not Get* when reading pref values in any even possibly warm code paths

[smaug]

Hi,

Preferences::GetBool is a slow hashtable lookup and has been showing up in 
performance profiles in many places.
Please use Preferences::AddBoolVarCache. Same with other pref types.
Or if the pref needs to be read just once, store the value in some static 
variable or so.



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

Re: Embeddable Browser

[Rodolpho Porto]

Em quarta-feira, 22 de fevereiro de 2017 00:53:00 UTC-3, 段垚  escreveu:
> For extended support (non-offical) of xulrunner-stub, see my project: 
> https://github.com/duanyao/xulrunner-stub
> 
> For embedable gecko in Winforms, see GeckoFX: https://bitbucket.org/geckofx/
> 
> 
> 在 2017/2/20 18:38, Rodolpho Porto 写道:
> > Hello guys,
> >
> > I do not know if this serious or the right group to do this ask, but I will 
> > try here rss
> >
> > Xulrunner no longer has updates, where do I find information or 
> > documentation from a substitute for it? I am currently researching 
> > information about Gecko and Firefox to set up an embeddable browser to 
> > replace what I did with Xulrunner, but I find little information, can 
> > anyone give me a light on this?
> >
> > Thank you: D
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform

Thank you very much for your answer, I will access these all the links that you 
have passed me: D
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Embeddable Browser

[Rodolpho Porto]

Em terça-feira, 21 de fevereiro de 2017 21:30:19 UTC-3, Myk Melez  escreveu:
> > Rodolpho Porto 
> > 2017 February 20 at 02:38
> > Hello guys,
> >
> > I do not know if this serious or the right group to do this ask, but I 
> > will try here rss
> >
> > Xulrunner no longer has updates, where do I find information or 
> > documentation from a substitute for it?
> Hi Rodolpho,
> 
> There isn't currently an exact substitute for XULRunner. The closest 
> alternative is to use a Firefox installation to run a XULRunner app by 
> invoking the Firefox executable with the --app command-line flag and a 
> path to the XULRunner app's application.ini file:
> 
> path/to/firefox --app path/to/application.ini
> 
> I've also been experimenting with alternative Gecko-based runtimes for 
> desktop apps, including Positron , 
> which is designed to be Electron-compatible, and a more minimal runtime 
> that provides existing Mozilla APIs along with tools for 
> running/packaging apps.
> 
> However, both of those projects are still in an experimental phase of 
> development, so they aren't necessarily suitable for general use.
> 
> > I am currently researching information about Gecko and Firefox to set 
> > up an embeddable browser to replace what I did with Xulrunner, but I 
> > find little information, can anyone give me a light on this?
> Can you describe your embeddable browser project in more detail? I'd 
> like to learn more about how you're thinking of using Gecko, and I may 
> also be able to give better advice once I understand your use case better.
> 
> -myk

Hello Myk Melez,

First of all, thank you for your response!

I'll talk about the project, it's a kiosk-style browser, using XULRunner 
24.0b10 32bit and SWT, the modifications we made were according to project 
needs and security requirements. All of this is in the testing phase, but the 
project is still evolving, the project is huge and XulRunner's share is small 
but of paramount importance.

This project currently runs in various parts of the country (Brazil) and is 
used by thousands of people, XULRunner comes as an evolution idea, but we need 
to update the firefox engine so we can no longer use XulRunner :( 

I am looking for solutions to present to the customer.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Doxygen output?

[Henri Sivonen]

On Tue, Feb 21, 2017 at 12:42 AM,   wrote:
> My short (<2yr) experience of the code gave me the impression that only a 
> small amount of it has proper doxygen comments.
> We must be frequenting different circles; or I'm somehow blind to them. :-)

I get to look at stuff like:
/**
 * Cause parser to parse input from given URL
 * @updategess5/11/98
 * @param   aURL is a descriptor for source document
 * @param   aListener is a listener to forward notifications to
 * @return  TRUE if all went well -- FALSE otherwise
 */

> Anyway, they're mainly useful when generated websites/documents are readily 
> available, which it seems isn't the case (anymore).

Right. I'm trying to assess how much effort I should put into writing
Doxygen-formatted docs, and if we aren't really publishing Doxygen
output, I feel like it's probably good to write /** ... */ in case we
start using Doxygen again but probably not worthwhile to use the @
tags.

On Tue, Feb 21, 2017 at 10:13 PM, Bill McCloskey  wrote:
> I've been thinking about how to integrate documentation into Searchfox. One
> obvious thing is to allow it to display Markdown files and
> reStructuredText. I wonder if it could do something useful with Doxygen
> comments though? Is this something people would be interested in?

I think integrating docs with Searchfox would be more useful than
having unintegrated Doxygen output somewhere. Compared to just reading
a .h with comments, I think a documentation view would be particularly
useful for templates and headers with a lot of inline definitions as a
means to let the reader focus on the interface and hide the
implementation (including hiding whatever is in a namespace with the
substring "detail" in the name of the namespace for templates).
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform