Moving from xulrunner to firefox SDK

[Manish]

Hi, 

I am working on a desktop application named "AZARDI" which is based on 
xulrunner. It is an offline ePub Reader for all three major platforms (Windows, 
Mac, Linux). You can check it out at http://azardi.infogridpacific.com/. 

I have been deploying the application successfully with xulrunner 41 and 
earlier. Its been long since Xulrunner has been deprecated so now I am planning 
to deploy it with firefox-sdk. But the problem is from where can I find the 
latest firefox SDK version for all the platforms eg: windows, linux and mac. 
Second can the directory structure remains the same as earlier like for 
xulrunner.

Any help will be useful. 

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

Re: New string types: nsAutoStringN<> and nsAutoCStringN<>

[Mike Hommey]

On Tue, Aug 22, 2017 at 04:38:04PM +1000, Nicholas Nethercote wrote:
> I really wish our top-level namespace was "moz", rather than "mozilla".

It's never too late to change it. I, for one, vote +1.

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

Re: New string types: nsAutoStringN<> and nsAutoCStringN<>

[Nicholas Nethercote]

I really wish our top-level namespace was "moz", rather than "mozilla".

Nick

On Tue, Aug 22, 2017 at 10:31 AM, Eric Rahm  wrote:

> On Mon, Aug 21, 2017 at 8:32 AM, Jonathan Kew  wrote:
>
> >
> > Wouldn't it be more "modern Gecko-ish", though, to drop the "ns" prefix,
> > and perhaps put Auto[C]String into the mozilla namespace?
> >
> >
> As Nick said, renaming all the things is a job for another day :)
>
> Coincidentally I have some pending changes that affect the internal naming
> of all of our strings. Externally (outside of xpcom/string) there will be
> no discernible change but I *could* move everything to the mozilla
> namespace and drop the 'ns' prefix. We could then gradually migrate to the
> new naming scheme externally. I think we'd eventually want to move the
> include path to 'mozilla/String.h' as well if we went this route, in the
> interim we could just have stubs that redirect to the mozilla path.
>
> I'm not sure how much backing that has -- we'd be going from nsString =>
> String which is pretty close to std::string -- it would be interesting to
> get some feedback.
>
> -e
> ___
> 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: New string types: nsAutoStringN<> and nsAutoCStringN<>

[Kris Maglione]

On Mon, Aug 21, 2017 at 05:31:14PM -0700, Eric Rahm wrote:

I'm not sure how much backing that has -- we'd be going from nsString =>
String which is pretty close to std::string -- it would be interesting to
get some feedback.


It's already a pretty common practice to have MFBT identifiers with 
the same names, aside from capitalization, as std classes with 
the same purpose(Vector, Move, Forward, DeclVal, ...), so that 
doesn't seem to be a major concern.

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

Re: New string types: nsAutoStringN<> and nsAutoCStringN<>

[Chris Peterson]

On 2017-08-21 5:31 PM, Eric Rahm wrote:

I'm not sure how much backing that has -- we'd be going from nsString =>
String which is pretty close to std::string -- it would be interesting to
get some feedback.


Or follow Rust's precedent and use type name `Str`. That would avoid 
confusion with std::string or #include "string.h" on case-insensitive 
file systems.

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

Re: New string types: nsAutoStringN<> and nsAutoCStringN<>

[Eric Rahm]

On Mon, Aug 21, 2017 at 8:32 AM, Jonathan Kew  wrote:

>
> Wouldn't it be more "modern Gecko-ish", though, to drop the "ns" prefix,
> and perhaps put Auto[C]String into the mozilla namespace?
>
>
As Nick said, renaming all the things is a job for another day :)

Coincidentally I have some pending changes that affect the internal naming
of all of our strings. Externally (outside of xpcom/string) there will be
no discernible change but I *could* move everything to the mozilla
namespace and drop the 'ns' prefix. We could then gradually migrate to the
new naming scheme externally. I think we'd eventually want to move the
include path to 'mozilla/String.h' as well if we went this route, in the
interim we could just have stubs that redirect to the mozilla path.

I'm not sure how much backing that has -- we'd be going from nsString =>
String which is pretty close to std::string -- it would be interesting to
get some feedback.

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

Photon Engineering Newsletter #13

[Jared Wein]

(via
https://msujaws.wordpress.com/2017/08/18/photon-engineering-newsletter-13/ )

This week I’m taking over for Dolske

as he takes a vacation to view the eclipse. This is issue #13
 of the Photon Engineering
Newsletter.

This past week the Nightly team has had some fun with the Firefox icon.
We’ve seen the following icons grace Nightly builds in the past week:

The icon in the top-left was created in 2011 by Sean Martell
. The icon in the
top-right was the original Phoenix icon. Phoenix was later renamed
Firebird, and then the name was later changed to Firefox
.
The icon in the bottom right was the first “Firefox” icon, designed by
Steven Garrity

in 2003. The icon in the bottom-right, well it is such logo with much
browser , we couldn’t help ourselves to
not share it.
Recent Changes Menus/structure:

The Report Site Issue button has been moved to the Page Action menu
 in Nightly and Dev
Edition. This button doesn’t ship to users on Beta or Release.

https://msujaws.files.wordpress.com/2017/08/2017-08-18_1554.png is a
screenshot of the Page Action menu.

Probably the biggest visual change this week is that we now have spacers in
the toolbar . These
help to separate the location bar from the other utility buttons, and also
keep the location bar relatively centered within the window. We have also
replaced the bookmarks menu button with the Library button (it’s the icon
that looks like books on a shelf).

https://msujaws.files.wordpress.com/2017/08/2017-08-18_1557.png is a
screenshot of the Nightly window with the spacers in place.

We also widened various panels
 to help fit more
text in them.
Animation:

The Pin to Overflow animation has also been tweaked
 to not move as far.
This will likely be the final adjustment to this animation (seen on the
left). The Pocket button has moved to the location bar and the button
expands when a page is saved
 to Pocket (seen on
the right).

Pin to Overflow animation:
https://msujaws.files.wordpress.com/2017/08/overflow.gif

Pocket animation: https://msujaws.files.wordpress.com/2017/08/pocket.gif
Preferences:

Preferences has continued to work towards their own visual redesign for
Firefox 57. New icons were landed for the various categories
 within Preferences,
and some borders  and
margins  have been
adjusted.
Visual redesign:

The tab label is no longer centered on Mac
. This now brings
Linux, Mac, and Windows to all have the same visual treatment for tabs.

Changing to Compact density within Customize mode changes the toolbar
buttons to now use less horizontal space. The following GIF shows the theme
changing from Compact to Normal to Touch densities.

Changing densities animation:
https://msujaws.files.wordpress.com/2017/08/density.gif
Onboarding:

New graphics for the onboarding tour
 have landed.


Performance:

Two of the main engineers focusing on Performance were on PTO this past
week so we don’t have an update from them.

​


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

Re: Quantum Flow Engineering Newsletter #20

[Olli Pettay]

On 08/18/2017 08:28 PM, Ehsan Akhgari wrote:

On Fri, Aug 18, 2017 at 9:39 AM, Ryan VanderMeulen mailto:rvandermeu...@mozilla.com>> wrote:

Is there a good way to get a sense of what the higher-impact bugs are that 
remain for improving Speedometer? Just going through the deps is
difficult because it's hard to assess how much of a win some of those are. 
Are we gated mostly on JS perf at this point? Layout? Something else? :-)


That's a pretty hard question to answer since in many cases the impact of each 
individual bug fix may fall below the measurement noise in the
benchmark score, and also it's pretty hard to map what you see in profiles to 
benchmark score numbers, except for bugs that have some kind of in
progress patch which allows us to measure the before and after state without 
them having been fixed yet.

In general Speedometer performance isn't generally gated on anything extremely 
big and instead has been improved by fixing many small performance
issues all over the place.  That being said, there are some "high profile" bugs 
that come to my mind.  Jan may think of some more in SpiderMonkey:

  * https://bugzilla.mozilla.org/show_bug.cgi?id=651120 I think will be able to 
gain us a few extra points but it's a complex change with many
dependencies and a few people are helping out Cătălin with it.  (Interestingly 
I just realized it wasn't on the dependency list of the main SM2 bug!)

/me would like to see some Speedometer numbers from a build with the patches 
for bug 651120


  * https://bugzilla.mozilla.org/show_bug.cgi?id=1346723 may also help some 
more still.  We have already done a ton of work under that bug, but
there's some more work to be done.  However this bug is getting closer to the 
state where most of the remaining work involves fixing many different
issues, each of which is costing a bit of the overall time spent there when 
running the benchmark.
  * https://bugzilla.mozilla.org/show_bug.cgi?id=1349255 is a sync IPC that 
hurts Speedometer so fixing it may have an outsized impact relative to
other bug fixes.
I thought this would affect Speedometer significantly, since it shows up in the profiles, but I disabled the sync message altogether and rerun and 
couldn't really see difference locally. Perhaps the sync calls happen usually when Speedometer isn't running tests but just loading pages or so.



  * https://bugzilla.mozilla.org/show_bug.cgi?id=1377131 may have a large 
impact also, but I'm not sure exactly how much.  Olli may be able to provide
more information about that.

Locally my patches seem to affect quite a lot on linux, but unfortunately less 
on Windows.



Cheers,
Ehsan


Thanks!

-Ryan

On Fri, Aug 18, 2017 at 1:26 AM, Ehsan Akhgari mailto:ehsan.akhg...@gmail.com>> wrote:

Hi everyone,

It is hard to believe that we've gotten to the twentieth of these 
newsletters.  That also means that we're very quickly approaching the finish
line for this sprint.  We only have a bit more than five more weeks to 
go before Firefox 57 merges to beta.  It may be a good time to start to
think more carefully about what we pay attention to in the remaining 
time, both in terms of the risk of patches landing, and the opportunity
cost of what we decide to put off until 58 and the releases after.

We still have a large number of triaged bugs


 that are available for someone to pick up
and work on.  If you have some spare cycles, we really would appreciate 
if you consider picking one or two bugs from this list and working on
them.  They span many different areas of the codebase so finding 
something in your area of interest and expertise should hopefully be simple.
Quantum Flow isn't the kind of project that requires fixing every 
single one of these bugs to be finished successfully, but at the same time
big performance improvements often consist of many small parts, so the 
cumulative impact of a few additional fixes can make a big impact.

It is worth mentioning that lately while lurking on various tech news 
and blog sites where Nightly users comment, I have seen quite a few
positive comments about Nightly performance from users.  It's easy to 
get lost in the details of the work involved in getting rid of
synchronous IPCs, synchronous layout/style flushes, unnecessary memory 
allocations, hashtable lookups, improving data locality, JavaScript JIT
performance, making sure code gets inlined better, ship a new CSS 
engine, etc. etc. but it is reassuring to see people
 take 
 notice

.
  :-)

Moving on to mention on

Re: New string types: nsAutoStringN<> and nsAutoCStringN<>

[Jonathan Kew]

On 20/08/2017 23:35, Nicholas Nethercote wrote:

Hi,

For a long time we have had types nsAutoString and nsAutoCString which are
strings with 64 chars of inline storage. They are good for holding short
strings, most often on the stack, because they avoid the need to heap
allocate
a char buffer.

I recently landed patches (bug 1386103) that introduce nsAutoStringN and
nsAutoCStringN. These are like the existing types but their length is a
template parameter. So if you want an nsString with 128 chars of inline
storage, you'd use nsAutoStringN<128>. If you want an nsCString with enough
inline storage to store an nsID you'd use nsAutoCStringN.


Nice!

Wouldn't it be more "modern Gecko-ish", though, to drop the "ns" prefix, 
and perhaps put Auto[C]String into the mozilla namespace?



nsAutoString and nsAutoCString have been redefined as typedefs for
nsAutoStringN<64> and nsAutoCStringN<64>, respectively.

I have updated the MDN docs appropriately:
https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/
Guide/Internal_strings

Nick

p.s. The "Auto" in these names is confusing. "Auto" in Mozilla code usually
refers to an RAII wrapper type such as AutoPtr or AutoLock. nsInlineString
and
nsInlineCString would be better names for these types... but that's a
change
for another day.


There's also AutoTArray, though, which uses "Auto" in the same sense as 
nsAutoString...


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

Re: New string types: nsAutoStringN<> and nsAutoCStringN<>

[Ben Kelly]

On Mon, Aug 21, 2017 at 10:00 AM, Ben Kelly  wrote:

> Should that be `mStorage[N + 1]`?
>

Maybe not since things like NSID_LENGTH include the null pointer on their
end.  Sorry for my confusion.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: New string types: nsAutoStringN<> and nsAutoCStringN<>

[Ben Kelly]

On Sun, Aug 20, 2017 at 6:35 PM, Nicholas Nethercote  wrote:

> Hi,
>
> For a long time we have had types nsAutoString and nsAutoCString which are
> strings with 64 chars of inline storage. They are good for holding short
> strings, most often on the stack, because they avoid the need to heap
> allocate
> a char buffer.
>
> I recently landed patches (bug 1386103) that introduce nsAutoStringN and
> nsAutoCStringN. These are like the existing types but their length is a
> template parameter. So if you want an nsString with 128 chars of inline
> storage, you'd use nsAutoStringN<128>. If you want an nsCString with enough
> inline storage to store an nsID you'd use nsAutoCStringN.
>
> nsAutoString and nsAutoCString have been redefined as typedefs for
> nsAutoStringN<64> and nsAutoCStringN<64>, respectively.
>

First, let me say this is a great addition.  Thanks!

I do have a question, though.  My impression was that something like
nsAutoCString stored its data in a null terminated string.  So you can do
things like:

  nsAutoCString someValue;
  printf_stderr("value = %s\n", someValue.get());

Does nAutoCStringN also store its value null-terminated?  Is that null
somehow accounted for in the storage?  I don't see where that is done:

http://searchfox.org/mozilla-central/source/xpcom/string/nsTString.h#664

Should that be `mStorage[N + 1]`?

Thanks.

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

[Firefox Desktop] Issues found: August 14th to August 18th

[Cornel Ionce]

Hi everyone,

Here's the list of new issues found and filed by the Desktop Release QA 
Team last week, *August 14 - August 18* (week 33).


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
1391267 
Conditional breakpoints can't replace disabled breakpoints
Firefox
Developer Tools: Debugger
NO  NOBODY
1391240 
Another, unwanted, breakpoint is created while holding ctrl + B
Firefox
Developer Tools: Debugger
NO  NOBODY
1391645 
	'An error occurred while printing" message is constantly displayed 
while trying to print vertical frames

Core
Printing: Output
	YES 
 
	Masayuki Nakano 



*NIGHTLY CHANNEL*
ID  Summary Product Component   Is a regression 
Assigned to
1390895 
Learn more label is not highlighted Firefox
Preferences
NO  Ricky Chien 


*ESR CHANNEL*
none


Regards,
Cornel (:cornel_ionce)
Desktop Release QA
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform