On Mon, Aug 18, 2014 at 12:19 AM, Yonggang Luo
wrote:
> 在 2014年8月17日星期日UTC+8下午2时44分34秒，Yonggang Luo写道：
> > I am trying to calling the JS API comes from C++,
> >
> > and need to transform the nsRect, so how to do the transformation.
>
> I found it's x/60, y/60,
> don't know where does this ratio c
On Sun, Aug 17, 2014 at 6:16 PM, Yonggang Luo wrote:
> Thanks, I means a backgound-image: URL(transparent.png)
> Will this image take effect
>
It should do, but transparent window backgrounds are not very well tested.
Rob
--
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoro
On Sun, Aug 17, 2014 at 3:41 PM, Yonggang Luo wrote:
> I want to preserve the aero effect of the Window, but I also need to
> customize the UI, so I need a transparent background image for the top
> level elemetn, is that possible?
>
Yes. Firefox does this. You need to set -moz-appearance:none
On Wed, Aug 13, 2014 at 4:35 AM, Aryeh Gregor wrote:
> On Tue, Aug 12, 2014 at 6:46 PM, L. David Baron wrote:
> > In these cases we document that it's likely safe for callers to do
> > this by having those getters return raw pointers. Getters that
> > require reference-counting return already_A
On Fri, Aug 1, 2014 at 11:24 AM, Jeff Walden wrote:
> One last note. UniquePtr is patterned on std::unique_ptr, the C++11
> standard version of this idiom. The current mozilla::Scoped class is
> another recent attempt to address largely the same needs. The older
> nsAutoPtr and nsAutoArrayPtr
On Thu, Jun 26, 2014 at 8:06 AM, Jason Orendorff
wrote:
> An alternative involves letting you modify JS code just before it's
> compiled (source-to-source transformation). This is more general (you could
> modify the instrumented code arbitrarily, and react synchronously as it
> executes) but may
See the thread in www-svg starting here:
http://lists.w3.org/Archives/Public/www-svg/2014Jun/0063.html
For the reasons mentioned in that thread, I'm against adding SVG elements
like that duplicate existing HTML elements, and I'm not the only
one.
Instead I think we should focus on extending HTML
On Wed, Jun 18, 2014 at 4:51 AM, Jonathan Kew wrote:
> If I'm reading bug 948856 correctly, the difference may have been somewhat
> less (150ms? comment 17) when the font was inlined in the CSS using a data
> URI, rather than loaded from a separate file
>
> If we can't afford that, then we still
On Mon, Jun 16, 2014 at 6:08 PM, Jonas Sicking wrote:
> A long time ago we talked about just writing a very low-level USB API,
> then enabling signed snippets of javascript to create page-exposed
> APIs on top of that. This way we wouldn't have to go through the long
> and expensive process of st
On Sun, Jun 15, 2014 at 11:24 AM, Leman Bennett (Omega X) <
Redacted.For.Spam@request.contact> wrote:
> Is that really necessary? It seems superfluous.
>
It's necessary in that there's no other way to use this hardware from a Web
app.
The only question is whether it's high-enough priority to wor
Looks good.
A classic problem we have had is with boolean parameters, which are hard to
read at call sites. We currently solve that by turning them into enum or
flag parameters, but named parameters would be a lighter-weight
alternative. However, it would be great to be able to ensure at the
langu
On Wed, Jun 11, 2014 at 10:41 AM, Kip Gilbert wrote:
> While beginning implementation I noticed that there is smooth
> scrolling functionality already implemented within
> ScrollFrameHelper::AsyncScroll, using simple splines via
> nsSMILKeySpline. This smooth scrolling behavior is used internall
On Fri, Jun 6, 2014 at 11:12 PM, Gijs Kruitbosch
wrote:
> No, I think that in 99.99% of cases, I don't care about the type, and
> therefore I would normally use is() and not care that it's using non-strict
> equality. I think the case where there is (a) a possibility that I could
> get '5' instea
On Fri, Jun 6, 2014 at 4:22 PM, Dirk Schulze wrote:
> What about
>
> DOMMatrix(1,0,0,1,0,0) or
> DOMMatrix(1,0,0,0,0,1,0,0,0,0,1,0,0,0,0,1)
>
> Do we check the values and determine if the matrix is identity or not? If
> we do, then authors could write DOMMatrix(other.a, other.b, o
On Fri, Jun 6, 2014 at 10:28 AM, Robert O'Callahan
wrote:
> On Fri, Jun 6, 2014 at 9:57 AM, Dirk Schulze wrote:
>
>> :) would be short enough I guess. But doesn’t sound serious enough.
>>
>
> translateSelf?
>
Or translateThis of course.
Rob
--
Jtehsauts tsh
On Fri, Jun 6, 2014 at 9:07 AM, Rik Cabanier wrote:
> There are 2 things that I have questions about:
> 1. isIdentity()
> We settled that this should mean that the matrix was never changed to a non
> identity state.
> This means that the following code:
>
> var m = new DOMMatrix();
>
> m.rotate(0
On Fri, Jun 6, 2014 at 9:57 AM, Dirk Schulze wrote:
> :) would be short enough I guess. But doesn’t sound serious enough.
>
translateSelf?
Rob
--
Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni
le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teo
So IIUC this means that script can't call any methods on these interfaces,
so the only remaining users could be binary extension components and those
within libxul itself. So if we're willing to ignore the former, and
eliminate the latter, then we can remove these interfaces entirely? Or do
we need
On Wed, Jun 4, 2014 at 10:42 AM, Rik Cabanier wrote:
> Going with Benoit's suggestion, we can change the idl for invert to:
>
> bool invert();
>
> and change inverse to return a matrix with NaN for all its elements.
>
Make it so!
Rob
--
Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehr
On Wed, Jun 4, 2014 at 10:26 AM, Rik Cabanier wrote:
> That would require try/catch around all the "invert()" calls. This is ugly
> but more importantly, it will significantly slow down javascript execution.
> I'd prefer that we don't throw at all but we have to because SVGMatrix did.
>
Are you
On Wed, Jun 4, 2014 at 10:23 AM, Robert O'Callahan
wrote:
> On Wed, Jun 4, 2014 at 1:13 AM, Benoit Jacob
> wrote:
>
>> This list misses some of the points that I care more about:
>> - Should DOMMatrix really try to be both 3D projective transformations
>>
On Wed, Jun 4, 2014 at 1:13 AM, Benoit Jacob
wrote:
> This list misses some of the points that I care more about:
> - Should DOMMatrix really try to be both 3D projective transformations
> and 2D affine transformations or should that be split into separate classes?
>
I raised this issue too a w
On Tue, Jun 3, 2014 at 3:28 PM, Rik Cabanier wrote:
> Yes, isIdentity is used as an indication that nothing needs to be done or
> that the transform hasn't changed.
> Maybe we should rename it to isDefault, isInitial or isNoOp?
>
I think isIdentity is the right name.
Glancing through Gecko I se
Off the top of my head, the places in Gecko I know of that use isIdentity
or is2D fall into two categories:
1) math performance optimizations
2) (is2D only) we're going to take an implementation approach that only
works for 2D affine transforms, and either a) there is no support for 3D
perspective
On Wed, May 21, 2014 at 9:53 PM, Robert O'Callahan
wrote:
> Android and B2G got fixed to use #pragma GCC visibility. So, we can go
> ahead and remove all NS_HIDDEN-related code now.
>
> This also means that when modifying Android and B2G-specific code that
> uses symbols
On Tue, Jun 3, 2014 at 4:24 AM, Martin Thomson wrote:
> > it conveys that this is a 2d matrix and that you can ignore the 3d
> components.
>
> Maybe you misunderstood what I was implying. You are describing an
> intended application of the matrix to 2d or 3d graphics. The problem is
> that the
On Mon, Jun 2, 2014 at 3:19 PM, Rik Cabanier wrote:
> isIdentity() indeed suffers from rounding errors but since it's useful, I'm
> hesitant to remove it.
> In our rendering libraries at Adobe, we check if a matrix is *almost*
> identity. Maybe we can do the same here?
>
One option would be to m
I'm all for it! :-)
Rob
--
Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni
le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa
stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr,
'm aotr atnod sgaoy ,h o'mGee.t" uTph ean
On Wed, May 28, 2014 at 6:14 AM, wrote:
> Is this behavior acceptable or would it be more desirable to always return
> the actual scroll position in DOM methods?
>
All DOM methods that depend on the scroll position (not just
scrollLeft/scrollTop but getBoundingClientRect etc too) should always u
On Wed, May 28, 2014 at 5:36 AM, Kearwood Gilbert <
kearwood.gilb...@gmail.com> wrote:
> My greatest concern is that as platform conventions change, this behavior
> could (or should) be updated to match. Web developers that depend on
> particular acceleration / deceleration curves or time to comp
On Mon, May 26, 2014 at 9:47 AM, Robert O'Callahan wrote:
> On Sun, May 25, 2014 at 4:59 PM, L. David Baron wrote:
>
>> On Saturday 2014-05-24 20:00 -0700, Jonas Sicking wrote:
>> > I guess what I'm arguing is that smooth-scrolling vs. instant
>> >
On Sun, May 25, 2014 at 4:59 PM, L. David Baron wrote:
> On Saturday 2014-05-24 20:00 -0700, Jonas Sicking wrote:
> > I guess what I'm arguing is that smooth-scrolling vs. instant
> > scrolling shouldn't be a per-element CSS property, but rather a
> > per-callsite API argument.
>
> I think I tend
On Fri, May 23, 2014 at 10:12 PM, Jonas Sicking wrote:
> How will "scroll-behavior: instant" work on platforms that use APZ? I
> worry about authors expect it to enable them to do a bunch of DOM
> mutations and then set the scroll position and allow them to be sure
> that rendering can't happen o
Android and B2G got fixed to use #pragma GCC visibility. So, we can go
ahead and remove all NS_HIDDEN-related code now.
This also means that when modifying Android and B2G-specific code that uses
symbols imported from other dynamic libraries, you will need to add to
config/system-headers (when inc
On Wed, May 21, 2014 at 1:11 PM, L. David Baron wrote:
> I wonder if the problem is that we're overusing namespaces (i.e., we
> have too many of them or put many classes at places too deeply
> nested in the namespace hierarchy)? Perhaps it makes sense to have
> a guideline that names shouldn't f
On Wed, May 21, 2014 at 4:36 AM, Nicolas Silva wrote:
> Honestly, I don't mean to start a bikeshed about whether we should enforce
> strict rules about this project-wise, because I know that people have
> different tastes as to whether writing "Size" is vastly better than
> "gfx::Size". But I'd li
Seems to me we should indicate pings in the link status text (bug 401352),
indicate pinging in the status text while we load the next page, and retain
the about:config pref to disable pinging.
The first two measures seem low-cost and constitute a strict improvement on
the current privacy situation
On Wed, May 7, 2014 at 12:31 PM, Kip Gilbert wrote:
> As of May 7, 2014 I intend to turn css sticky positioning on by default
> for desktop (already enabled on B2G). It has been developed behind the
> layout.css.sticky.enabled preference.
>
> This feature has been enabled for some time on mobile,
On Tue, May 6, 2014 at 5:57 PM, Ian Hickson wrote:
> Just so we're clear, I really don't care what the name is, nor do I have
> any objection to people having private conversations or whatnot. My point
> is just that there has not been a conversation in the WHATWG list about
> this which has resu
On Tue, May 6, 2014 at 4:44 PM, Rik Cabanier wrote:
> FWIW the discussion was public.
> See
> http://lists.w3.org/Archives/Public/public-canvas-api/2014JanMar/0003.html
>
Haha, OK, apology withdrawn :-).
Thanks,
Rob
--
Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni
l
On Tue, May 6, 2014 at 4:13 PM, Ian Hickson wrote:
> On Tue, 6 May 2014, Robert O'Callahan wrote:
>
> > We could probably come up with a slightly better name, but only very
> > slightly better, so at this point I would rather not reopen the
> > discussion. If someon
On Tue, May 6, 2014 at 8:13 AM, Ian Hickson wrote:
> drawFocusIfNeeded() isn't a particularly good name either, since you're
> not drawing the focus, you're drawing the focus ring.
>
In the old email thread, Jatinder Mann objected to using the term "ring"
since the focus drawn might not look lik
Yes please!
Rob
--
Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni
le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa
stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr,
'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwe
On Fri, May 2, 2014 at 7:12 AM, Ian Hickson wrote:
> On Thu, 1 May 2014, Rik Cabanier wrote:
> > No particular reason. The spec text is identical; just the name of the
> > method changed. Roc suggested the new name and people liked it better. I
> > believe Ian stated that he would update the WHAT
On Wed, Apr 23, 2014 at 11:48 AM, Mike Hommey wrote:
> On Tue, Apr 22, 2014 at 07:25:46PM -0400, Trevor Saunders wrote:
> > > No, that's just how we choose between #pragma visibility and
> > > -fvisibility=hidden
> >
> > Well, its at least strange given the bugs mentioned in configure were
> > su
On Wed, Apr 23, 2014 at 1:25 AM, Benjamin Smedberg wrote:
> On 4/22/2014 7:31 AM, Robert O'Callahan wrote:
>
>> It's all over the tree, inconsistently applied. Is it relevant anymore?
>> Can
>> we remove it entirely, or there some places where it's still
It's all over the tree, inconsistently applied. Is it relevant anymore? Can
we remove it entirely, or there some places where it's still relevant, and
if so, where ... XPCOM? Or should we be using it everywhere?
Rob
--
Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni
le a
The Timelapse project is cool but this thread got derailed. We have a long
list of future improvements to make to rr, and improving support for JS
debugging is on that list.
The point of this thread is that if you're debugging intermittent test
failures and you don't need much JS debugging then yo
Building a debugger for a high-level language on top of a low-level
recording is unexplored territory but it's definitely possible and it would
have some nice features. However, you can't get much leverage from any
existing debugging support built into a VM.
We could build some JS debugging suppor
On Wed, Apr 16, 2014 at 11:14 PM, Till Schneidereit <
t...@tillschneidereit.net> wrote:
> At the JS work week in Toronto in late March, we discussed this.
> Unfortunately, that was one of the relatively few sessions for which no
> protocol exists. :(
>
> The gist of the results was that, sadly, th
On Wed, Apr 16, 2014 at 11:14 AM, Vladimir Vukicevic wrote:
> Note that for purposes of this discussion, "VR support" is minimal.. some
> properties to read to get some info about the output device (resolution,
> eye distance, distortion characteristics, etc) and some more to get the
> orientation
On Wed, Apr 16, 2014 at 12:24 PM, Ted Mielczarek wrote:
> Do you have any idea on a timeframe for x86-64 support?
>
It's technically not that hard, but it's a reasonably large project so it's
not going to happen right away.
Rob
--
Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraii
On Wed, Apr 16, 2014 at 11:14 AM, Gijs Kruitbosch
wrote:
> 1) Is anyone working on something similar that works for frontend code
> (particularly, chrome JS)? I realize we have a JS debugger, but sometimes
> activating the debugger at the wrong time makes the bug go away, and then
> there's timing
On Wed, Apr 16, 2014 at 11:05 AM, Robert O'Callahan wrote:
> 1) Install rr on a Westmere-or-later Linux system (or VM with performance
> counters virtualized), build 32-bit Firefox (opt or debug) and verify that
> recording Firefox works for you. If it doesn't, please file
On Wed, Apr 16, 2014 at 11:05 AM, Robert O'Callahan wrote:
> 4) Create a script somewhere called rr-record that does "exec ~/rr/bin/rr
> record $*"
>
Sorry; this script, of course, needs to exec rr from wherever it was
installed.
Rob
--
Jtehsauts tshaei dS,o
We just released rr 1.2 and I think this would be a good time for people to
try to use it for one of the tasks it was designed for: debugging
intermittent test failures.
Consult http://rr-project.org for more information, but the gist is this:
you can use rr to record the execution of Firefox test
On Wed, Apr 16, 2014 at 3:14 AM, Benoit Jacob wrote:
> If VR is not yet a thing on the Web, could you elaborate on why you think
> it should be?
>
> I'm asking because the Web has so far mostly been a common denominator,
> conservative platform. For example, WebGL stays at a distance behind the
>
On Tue, Apr 15, 2014 at 10:41 AM, Vladimir Vukicevic wrote:
> I have a prototype of VR display and sensor integration with the web,
> along with an implementation for the Oculus VR. Despite there really being
> only one vendor right now, there is a lot of interest in VR. I'd like to
> add the we
On Sat, Apr 12, 2014 at 8:29 AM, Gregory Szorc wrote:
> I came across the following articles on source control and code review:
>
> * https://secure.phabricator.com/book/phabflavor/article/
> recommendations_on_revision_control/
> * https://secure.phabricator.com/book/phabflavor/article/
> writin
When you say "debug", you mean the emulator is running a FirefoxOS debug
build, not that the emulator itself is built debug --- right?
Given that, is it a correct summary to say that the problem is that the
emulator is just too slow?
Applying time dilation might make tests green but we'd be left
On Wed, Apr 2, 2014 at 12:11 AM, Joshua Cranmer 🐧 wrote:
> My original design for mozilla::Atomic was meant to avoid what I saw as
> the biggest footgun: you cannot misuse mozilla::Atomic in such a way that
> you combine atomic and non-atomic accesses on a single variable. You also
> cannot mix-an
DOMRect, DOMPoint and DOMQuad are defined in the Geometry Interfaces spec:
http://dev.w3.org/fxtf/geometry/Overview.html
GeometryUtils is defined in the CSSOM View spec:
http://dev.w3.org/csswg/cssom-view/#geometry
The spec for the GeometryUtils methods is quite incomplete but we've
discussed the s
Sounds good :-)
Rob
--
Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni
le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa
stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr,
'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt
On Wed, Mar 5, 2014 at 8:47 AM, Felipe G wrote:
> If I go with the clone route (to work on the snapshot'ed version of the
> data), how can I later associate the cloned nodes to the original nodes
> from the document? One way that I thought is to set a a userdata on the
> DOM nodes and then use t
On Tue, Mar 4, 2014 at 9:19 AM, Boris Zbarsky wrote:
> How feasible is just doing .innerHTML to do that, then doing some sort of
> async parse (e.g. XHR or DOMParser) to get a DOM snapshot? That said, this
> would mean that you end up with a snapshot that's actual DOM stuff, on the
> main thread
On Wed, Feb 12, 2014 at 9:18 AM, Reed Loden wrote:
> I do like the slickness and quickness, but it still seems
> greatly-lacking usability-wise (as compared to mxr)...
>
> A few things off the top of my head:
> * Where are the non-mozilla-central repositories?
> * Where's the integration with CVS
On Tue, Feb 11, 2014 at 8:23 PM, Botond Ballo wrote:
> I think at least one of the goals of the standard drawing API is to
> make C++ easier to learn by allowing people learning the language
> to create simple graphical applications without having to set up
> third-party libraries or learn a comp
On Mon, Feb 10, 2014 at 12:00 PM, Brian Smith wrote:
> I don't think it is fixed in stone that asm.js code must go through
> Web Platform APIs. I believe the requirement is that it must be
> possible to translate asm.js code into Web Platform APIs in a way
> where the result works reasonably. AFA
On Mon, Feb 10, 2014 at 11:49 AM, Brian Smith wrote:
> On Sun, Feb 9, 2014 at 2:38 PM, Robert O'Callahan
> wrote:
> > I've already given my feedback on the cairo mailing list. Summary: Moz2D
> is
> > the right thing for us, and probably for other applic
I've already given my feedback on the cairo mailing list. Summary: Moz2D is
the right thing for us, and probably for other application frameworks, but
for applications that just want to draw their stuff on the screen or to
print, cairo might be a better fit. Anyway ti doesn't really matter to us
wh
On Thu, Feb 6, 2014 at 6:58 PM, Rik Cabanier wrote:
> We would like to ship mix-blend-mode too. In our experiments, Firefox has
> the most stable implementation. (We only have 1 open bug )
> However, we're taking a slow path today and it might take us a while to
> implement the fast path.
> We're
On Wed, Feb 5, 2014 at 8:33 PM, Masayuki Nakano wrote:
> I filed bug 968056 for changing our keypress event behavior for
> conformance with D3E definition.
> https://bugzilla.mozilla.org/show_bug.cgi?id=968056
>
> In D3E definition, keypress event shouldn't be fired for non-printable
> keys like a
On Wed, Jan 22, 2014 at 6:27 AM, Jeff Muizelaar wrote:
> On Jan 20, 2014, at 5:48 PM, Matt Woodrow wrote:
> > - A fully transparent surface containing only text. It should be fairly
> easy to get this to happen by 3d transforming a element. I suspect
> we don't want subpixel AA here, since we ha
On Thu, Jan 23, 2014 at 12:58 PM, Neil wrote:
> I have a vague memory of seeing either a m.d.platform or blog post
> mentioning the use of transforms as an alternative to absolute or relative
> positioning, in particular avoiding reflows by its use of layers.
>
> Does this apply to all transforms
Congratulations! This has been an epic journey :-).
Rob
--
Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni
le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa
stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr,
'm aotr atn
On Wed, Jan 8, 2014 at 9:46 AM, Mike Hoye wrote:
> On 1/7/2014, 3:22 PM, Adam Roach wrote:
>
>>
>> Since people are introducing actual research information here, let's run
>> some numbers. According to Paterson et. al. [1], reading comprehension
>> speed is actively hindered by lines that are eit
I agree that those are the current best practices.
We have a lot of places where we write "void Method() { ... }" all on one
line for trivial setters and getters. I wonder if we should permit that.
We have a lot of places where the opening brace of a class declaration is
on the same line as the c
On Tue, Jan 7, 2014 at 1:46 PM, Jeff Walden wrote:
> JS widely uses 99ch line lengths (allows a line-wrap character in 100ch
> terminals). Given C++ symbol names, especially with templates, get pretty
> long, it's a huge loss to revert to 80ch because of how much has to wrap.
> Is there a reaso
On Tue, Jan 7, 2014 at 10:27 AM, Brian Smith wrote:
> AFAICT, there are not many rules that module owners are bound by.
There are lots of tree-wide or Gecko-wide rules that module owners are
bound by.
> The
> reason module owners can dictate style is because module owners can
> dictate everyt
On Tue, Jan 7, 2014 at 7:06 AM, Bobby Holley wrote:
> * There are a lot of SpiderMonkey hackers who don't hack on anything else,
> and don't consider themselves Gecko hackers.
>
This has always bothered me a lot. It needs to change.
Rob
--
Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanutt
On Wed, Dec 25, 2013 at 11:54 AM, Nicholas Nethercote <
n.netherc...@gmail.com> wrote:
> On Mon, Dec 23, 2013 at 8:45 PM, Robert O'Callahan
> wrote:
> > That's a mistake. Module owners don't have the authority to make up their
> > own style. Who h
I think the best way to expend energy on this topic would be to work on
tools.
https://bugzilla.mozilla.org/show_bug.cgi?id=875605 seems worth getting
over the line. Some other kind of checker, possibly based on clang-format,
could also be a fine alternative. Just get something working that is
con
On Fri, Dec 20, 2013 at 2:35 PM, Jeff Gilbert wrote:
> Personally, there are a couple of things I don't like about moz-style
> (though revisions to the central style guide at least have made it better
> than it used to be), but instead of bikeshedding the central style guide,
> we just do our own
On Fri, Dec 13, 2013 at 3:02 PM, Chris Peterson wrote:
> On 12/12/13, 5:09 PM, L. David Baron wrote:
>
>> The preferred form would now be:
>>
>>#include "mozilla/Char16.h"
>>
>>const PRUnichar *comma = MOZ_UTF16(",");
>>
>
> I think char16_t is preferred over PRUnichar for new code.
>
So
On Wed, Dec 11, 2013 at 10:50 AM, Benoit Jacob wrote:
> 2013/12/10 Robert O'Callahan
>
>> Keep in mind that proliferation of different types for the same
>> functionality hurts developer productivity in various ways, especially
>> when
>> they have quite dif
On Wed, Dec 11, 2013 at 10:29 AM, Chris Pearce wrote:
> It seems to me that we should be optimizing for developer productivity
> first, and use profiling tools to find code that needs to be optimized.
>
> i.e. we should be able to use STL containers where we need basic ADTs in
> day-to-day coding
Maybe we can build something clever based on the per-window volume and
muting infrastructure in bug 923247? I think easy per-tab muting is a good
thing to try here.
Rob
--
Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni
le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?
Don't these arguments apply to desktop Firefox used at work, in an Internet
cafe, or in a library, as well?
I think it's important to have an easy way to mute/unmute the browser, but
disabling autoplay is probably not the right way to address these issues.
Rob
--
Jtehsauts tshaei dS,o n" Wohfy
Bill McCloskey pointed me to bug 924253, and his patch there fixed my
problem.
So basically, don't trust mochitest output until bug 924253 is fixed.
Rob
--
Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni
le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha i
I can reproducibly (but nondeterministically) reproduce a problem where
setting NSPR_LOG_MODULES, but not NSPR_LOG_FILE, redirecting stdout and
stderr to a file using bash >&, and using "mach mochitest-plain", the
occasional log message gets dropped. This can be very disturbing when
trying to debug
If everyone puts "using namespace foo;" inside "namespace mozilla {}", that
won't help much, right?
I'd prefer to minimize the source code changes required here. A tinderbox
non-unified build seems like the way to go.
Rob
--
Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eov
On Tue, Nov 26, 2013 at 12:46 AM, Henri Sivonen wrote:
> We have a concept of platform charset that goes back to pre-NT
> Windows, Mac OS Classic, OS/2 and pre-UTF-8 *nix platforms. This
> concept gets in the way of doCOMtaminating old code to use only new
> facilities in mozilla::dom::EncodingUti
On Thu, Nov 21, 2013 at 11:06 AM, Zack Weinberg wrote:
> On 2013-11-20 12:37 PM, Benoit Jacob wrote:
>
>> Talking about ideas for further extending the impact of UNIFIED_SOURCES,
>> it
>> seems that the biggest limitation at the moment is that sources can't be
>> unified between different moz.bui
On Tue, Nov 19, 2013 at 4:04 PM, L. David Baron wrote:
> I expect that otherwise we'd get pretty frequent bustage with people
> forgetting to add #includes, and that bustage would then show up
> when we add or remove files, which would make it a huge pain to add
> or remove files.
>
> But I'm act
On Tue, Nov 19, 2013 at 3:32 PM, Mike Hommey wrote:
> FWIW, there's an open bug to fold gkmedias back into xul, but it looks
> like it's not going to happen soon.
> https://bugzilla.mozilla.org/show_bug.cgi?id=922912
>
Egad! Oh well.
Rob
--
Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanut
Lovely!!!
On Tue, Nov 19, 2013 at 3:02 PM, Mike Hommey wrote:
> - FINAL_LIBRARY defines what library your code is going to be linked
> into. That needs to match an existing LIBRARY_NAME in some other
> moz.build. Most code will go in either xul, gkmedias or gklayout. Note
> gklayout may go
On Tue, Nov 19, 2013 at 3:31 AM, Boris Zbarsky wrote:
> While true, in the new setup we have a different problem: adding or
> removing a .cpp file makes other random .cpp files not compile.
>
I don't think we should worry much about this until we have more data on
how often it's a problem in pra
On Wed, Nov 13, 2013 at 5:09 AM, David Rajchenbach-Teller <
dtel...@mozilla.com> wrote:
> Or we could not save dynamic iframes in non-current positions in the
> history.
>
Does this mean that currently, if a page creates an IFRAME, loads url A
into it, then loads url B into it, sessionstore.js wi
When you say "iframes" you mean content documents that aren't toplevel
content documents, right?
Can you explain why sessionstore.js needs to observe non-toplevel-content
documents at all? I assume there's an obvious answer, I just don't know
what it is :-).
Rob
--
Jtehsauts tshaei dS,o n" Wohf
On Sat, Nov 9, 2013 at 7:32 PM, Benjamin Smedberg wrote:
> Is there a chrome-only API like .elementFromPoint that will tell me which
> XBL anonymous element is at a point?
>
I don't think so. You probably need to add another parameter to
nsIDOMWindowUtils::nodesFromRect (threaded through to
nsDoc
201 - 300 of 497 matches
Mail list logo
