Re: New chrome-only API to inject content on top of the page

[Neil]

Patrick Brosset wrote:

The discussion [2] that led to the bug was about finding a solution to 
display the devtools highlighter (the box-model overlay you see when 
inspecting a page with the devtools) in a way that would work on 
anything that runs gecko (indeed, prior to this bug, the devtools 
highlighter markup would be appended to one of the page's parent XUL 
node, which didn't work on B2G or Fennec, or with e10s enabled).


What's going to happen to the :-moz-devtools-highlighted pseudoclass?

--
Warning: May contain traces of nuts.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Problem with batch logging

[Josip Maras]

Hi, 

Mike, Ehsan, and David, thank you!

In the end, I added the Logging functionality to mozglue, exported it, and 
imported it wherever necessary. Now it works as expected, and there are no 
noticeable hangings even when working with large applications (e.g. facebook). 

Just in case, if a beginner like me, runs into a similar problem, this link was 
also useful: http://msdn.microsoft.com/en-us/library/ms235636.aspx

Thank you,

Josip


On Wednesday, October 29, 2014 12:19:03 AM UTC+1, Mike Hommey wrote:
> On Wed, Oct 29, 2014 at 08:08:23AM +0900, Mike Hommey wrote:
> > On Tue, Oct 28, 2014 at 11:56:49AM -0400, Ehsan Akhgari wrote:
> > > On 2014-10-28 4:16 AM, Josip Maras wrote:
> > > >Hi Ehsan,
> > > >
> > > >Yes, in my opinion that is the problem. I'm trying to use the global 
> > > >stream variable across module boundaries, more specifically from the 
> > > >following source files: content\base\src\Element.cpp; 
> > > >layout\style\nsCSSParser.cpp; content\base\src\nsINode.cpp, 
> > > >js\src\builtin\Eval.cpp, js\src\vm\Interpreter.cpp, js\src\jsfun.cpp, 
> > > >browser\app\nsBrowserApp.cpp, content\base\src\nsDocument.cpp, 
> > > >dom\base\nsGlobalWindow.cpp, parser\html\nsHtml5TreeOperation.cpp, 
> > > >content\html\document\src\nsHTMLContentSink.cpp
> > > >
> > > >So it's across at least two different modules.
> > > >
> > > >I've tried to follow your advice in using MOZ_EXPORT and MOZ_IMPORT, but 
> > > >I'm not getting anywhere :-/ The application runs, but it crashes.
> > > >
> > > >Of the top of your head, do you maybe know of a variable that is used in 
> > > >a similar way, so that I can look into how this is supposed to be done.
> > > >For example, if I wanted to create a stream in nsBrowserApp.cpp and then 
> > > >use that stream from the other files what should I do?
> > > >
> > > >Do I put:
> > > >
> > > >extern MOZ_EXPORT std::stringstream FC_LOG_STREAM; in that file (or in 
> > > >the header included from that file, and then i define the varible in the 
> > > >.cpp file) and then use MOZ_IMPORT std::stringstream FC_LOG_STREAM; in 
> > > >the other files/headers or?
> > > >
> > > >Sorry for taking up your time, but getting into the source code of 
> > > >Firefox, especially since I've done very little real world development 
> > > >in C++ is a bit overwhelming. Any help will be appreciated!
> > > 
> > > These macros just expand to __declspec(dllimport/dllexport), which is
> > > documented here: 
> > > Hopefully you can fix your problem following those instructions.  Note 
> > > that
> > > due to the nature of how we load xul.dll (which is done dynamically at
> > > runtime), I think your best bet is to export the variable from firefox.exe
> > > and import it in xul.dll, otherwise firefox.exe will not load because it
> > > will try to import a symbol from xul.dll but that DLL does not exist at
> > > startup time.
> > 
> > It's not possible to use a symbol in an executable from a dll. Not
> > directly.
> 
> The best place for something that needs to be shared between firefox.exe
> and xul.dll is mozglue.dll. Both are linked against it.
> 
> Mike
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: New chrome-only API to inject content on top of the page

[Patrick Brosset]

On 10/29/14, 12:29 PM, Neil wrote:

Patrick Brosset wrote:

The discussion [2] that led to the bug was about finding a solution 
to display the devtools highlighter (the box-model overlay you see 
when inspecting a page with the devtools) in a way that would work on 
anything that runs gecko (indeed, prior to this bug, the devtools 
highlighter markup would be appended to one of the page's parent XUL 
node, which didn't work on B2G or Fennec, or with e10s enabled).


What's going to happen to the :-moz-devtools-highlighted pseudoclass?

We currently still use this pseudoclass for highlighting nodes in XUL 
windows.


The new API only works with HTML windows (where the canvas frame 
exists), and so for XUL windows, we fall back to using the, simpler, red 
outline highlighter we've been using for a while now on b2g/fennec/e10s.

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

ARMv6 support is broken and its Tier status is at risk

[Chris Jones]

​tl;dr a libvpx update last week broke armv6.  Build system hackery is
needed to fix it.

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

This is relevant to you if you're a (i) stakeholder in an ARMv6 target;
(ii) decision maker about Tier support; (iii) build system expert.

The libvpx update changed the way optional NEON fastpaths are compiled into
libxul.  Previously they were written in assembly.  Now they're written as
C files that use NEON intrinsics.  The gory details are in the bug, but
essentially what's needed to fix the brokenness for ARMv6 is supplying
file-specific compiler options to the files that use NEON intrinsics.  If
you know how to do this or have better ideas for a solution, please head
over to the bug! :)

It would be a shame for the support for Firefox OS on the Raspberry Pi, for
example, to be dead-on-arrival because of a build-system issue.

Cheers,
Chris

p.s. I don't read this mailing list, please follow up in the bug.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Web APIs documentation meeting Friday at 10 AM PDT

[Eric Shepherd]

The Web APIs documentation meeting is Friday at 10 AM Pacific Time (see 
http://bit.ly/APIdocsMDN for your time zone). Keep in mind that the 
United States is still on Daylight Saving (summer) Time.


Everyone's welcome to attend; if you're interested in ensuring that all 
Web APIs are properly documented, we'd love your input.


We have an agenda, as well as details on how to join, here:

https://etherpad.mozilla.org/WebAPI-docs-2014-10-31.

If you have topics you wish to discuss, please feel free to add them to 
the agenda.


We look forward to seeing you there!

If you're unable to attend but have been working on documentation 
related to APIs, please add notes to the agenda about what you've been 
doing so we can share your progress.



--
Eric Shepherd
Developer Documentation Lead
Mozilla
Blog: http://www.bitstampede.com/
Twitter: @sheppy

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

Re: profiler in TB

[Benoit Girard]

The profiler addon on TB shouldn't be using the panel. It has another
piece of UI because jetpack doesn't support the panel in TB. Adding
that support will make these issues go away of course. Since it's the
same code base it's likely just a regression where the panel code is
used in shared code.

Currently there's an old build of the addon that should still work:

https://dl.dropboxusercontent.com/u/2921989/geckoprofiler.xpi

However it sounds like not all the TB symbols are being uploaded to
the symbol server.

On Sun, Oct 26, 2014 at 2:56 AM, Philip Chee  wrote:
> On 26/10/2014 10:48, ISHIKAWA,chiaki wrote:
>> Hi,
>>
>> I thought I try profiler to see how it works in TB, but
>> I get the following error.
>> It looks a module called |panel| is not usable in
>> TB.
>> I looked at jetpack-panel-apps web page noted in the message, but
>> am clueless.
>>
>> Error Message:
>> error: geckoprofiler: An exception occurred.
>> Error: The panel module currently supports only Firefox.  In the future
>> we would like it to support other applications, however.  Please see
>> https://bugzilla.mozilla.org/show_bug.cgi?id=jetpack-panel-apps for more
>> information.
>> resource://jid0-edalmuivkozlouyij0lpdx548bc-at-jetpack/addon-sdk/lib/sdk/panel.js
>> 12
>> Traceback (most recent call last):
>>File "resource://gre/modules/NetUtil.jsm:123", line 17, in
>> NetUtil_asyncOpen/<.onStopRequest
>>File
>> "resource://jid0-edalmuivkozlouyij0lpdx548bc-at-jetpack/addon-sdk/lib/sdk/net/url.js:49",
>> line 9, in readAsync/<
>>   [...]
>
> For panel.js etc please see:
>
> Bug 1023661 - Add support for SeaMonkey (and Thunderbird)
> https://bugzilla.mozilla.org/show_bug.cgi?id=1023661#c3
>> After these smoke tests I think context-menu.js, selection.js and
>> panel.js can be marked SeaMonkey compatible.
>
> Bug 1071048 - update sdk/tabs metadata to work in SeaMonkey (for Ghostery)
> https://bugzilla.mozilla.org/show_bug.cgi?id=1071048
>
> Phil
>
> --
> Philip Chee , 
> http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
> Guard us from the she-wolf and the wolf, and guard us from the thief,
> oh Night, and so be good for us to pass.
> ___
> 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: Memory tools documentation overhaul

[Steve Fink]

On 10/28/2014 11:16 PM, Nicholas Nethercote wrote:
> On Tue, Oct 28, 2014 at 9:17 PM, Nicholas Nethercote
>  wrote:
>> Both of these pages now just contain a single link to
>> https://developer.mozilla.org/en-US/docs/Mozilla/Performance, which has a new
>> section "Memory profiling and leak detection tools" with links to pages for 
>> all
>> of our tools:
>>
>> - about:memory
> Relatedly, I've just added a new section to this page. It contains
> instructions for non-experts on how to generate memory reports, e.g.
> for attaching to a bug or writing as a comment on a website. See
> https://developer.mozilla.org/en-US/docs/Mozilla/Performance/about:memory#How_to_generate_memory_reports

\o/

I think this is really important. Thank you for doing this! How can we
get this included in the automated support snippets that
support.mozilla.com seems to use?

Also, in reading through the document, I wonder if it would be useful to
add a "File a bug" link to about:memory? Or would that be a source of
too much noise? (I'm not sure how to make it auto-upload the memory
report, either.)

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

Re: Treating bugs with the appropriate degree of importance

[Gavin Sharp]

I'm not sure a productive discussion can be had on such a broad topic
without specific examples or suggestions :)

It's important to note, I think, that the existence of disagreements
about prioritization, controversial bugs, and missed issues is an
unavoidable reality of running a large, open software project.
Obviously, to be a well-run project, it's important to be constantly
trying to improve processes and systems to avoid missing or failing to
prioritize important issues, but "importance" can be a very subjective
thing, and eliminating disagreements entirely is just not possible.

Gavin

On Wed, Oct 29, 2014 at 3:38 PM, Drew DeVault  wrote:
> I was mistaken - for some reason I thought it was not fixed. Still,
> though, it's a good example for the problems with bugzilla, and the
> topic as a whole is still worth discussing.
>
> (cc: dev-platform)
>
> On 10/29/2014 04:38 PM, Gavin Sharp wrote:
>> Hey Drew,
>>
>> The bug you linked to is fixed, and if all goes well the fix will be
>> released in Firefox 35. Can you perhaps elaborate on why you think it
>> was "incorrectly closed"?
>>
>> (It may be best to redirect this thread to dev.platform, since that's
>> the best place to discuss bugs in platform code like that one.)
>>
>> Gavin
>>
>> On Wed, Oct 29, 2014 at 2:26 PM, Drew DeVault  wrote:
>>> Hey guys. I'm wondering if the process of triaging and addressing bugs on
>>> Bugzilla is being handled well. Today, I found this bug:
>>>
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=649849
>>>
>>> This is not the first bug whose severity I feel has been misjudged, but it
>>> is the one that made me decide to bring it up here. This bug is 3 and a half
>>> years old, with 222 votes. If it weren't incorrectly closed, it would be #4
>>> on the most voted bugs in Core. It's clearly a problem and has been for a
>>> long time, and the (justified) complaints about its idle state are met with
>>> hostility. This bug is unique among high-voted bugs because it is low risk
>>> and (presumably) easy to solve.
>>>
>>> I've seen other bugs like this, and I'm wondering if Bugzilla is being
>>> handled appropriately. I think it's clear that this bug should have been
>>> dealt with a long time ago. How are bugs prioritized and why is it the case
>>> that long-standing, important bugs can fall behind so easily? What can we do
>>> about it?
>>>
>>> --
>>> Drew DeVault
>>> ___
>>> firefox-dev mailing list
>>> firefox-...@mozilla.org
>>> https://mail.mozilla.org/listinfo/firefox-dev
>
> ___
> 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

Further changes to executables/library definitions in moz.build

[Mike Hommey]

Hi,

I just landed bug 1077148, which changes further how executables and
libraries are defined in moz.build, hopefully all for the best.

As usual, you can check the documentation in the tree in
build/docs/defining-binaries.rst or on
https://ci.mozilla.org/job/mozilla-central-docs/Tree_Documentation/
(once bug 1077148 is merged to mozilla-central)

Mike

PS: This is likely to break comm-central until it's adapted to use
the new templates.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform