I agree with Karl that, the 'a' prefix sometimes helps me in that way
when I read code. Also it is sometimes convenient to have a local
variable use the parameter name without the prefix, like:
> SomeType foo = CastOrUnwrap(aFoo);
I don't have strong opinion on this, though. If the majority of the
I like 'aFoo'.
Nick
On Tue, Jul 7, 2015 at 1:12 PM, Jeff Gilbert wrote:
> I propose that we stop recommending the universal use of an 'a' prefix for
> arguments to functions in C and C++. If the prefix helps with
> disambiguation, that's fine. However, use of this prefix should not be
> prescrib
I am in favor of getting rid of aFoo.
-Ekr
P.S. At the risk of convincing people I am crazy and thus discounting
my opinion above, I rather prefer foo_ to mFoo, but this seems like more
a matter of taste.
On Mon, Jul 6, 2015 at 8:55 PM, Robert O'Callahan
wrote:
> On Tue, Jul 7, 2015 at 3:26 P
Jeff Gilbert writes:
> we should have a good reason or
> two for making our choice. No such reason is detailed in the style guide.
I find the 'a' prefix useful to tell me that this variable has the
value that was provided to the function.
(I'm assuming that the prefix is used with this convention
On Tue, Jul 7, 2015 at 3:26 PM, Mike Hommey wrote:
> The existence of aFoo goes along with the existence of mFoo, sFoo, kFoo,
> and others I might have forgotten. Not that I particularly care about
> aFoo, but why strike this one and not the others?[1]
FWIW many coding styles do have special st
On Monday 2015-07-06 23:25 -0400, Hubert Figuière wrote:
> On 06/07/15 11:12 PM, Jeff Gilbert wrote:
> > I propose that we stop recommending the universal use of an 'a' prefix for
> > arguments to functions in C and C++. If the prefix helps with
> > disambiguation, that's fine. However, use of this
I don't feel all that strongly about aFoo, but mFoo is incredibly important
for reviewing code when the reviewer isn't intimately familiar with the
code being changed (dom/ reviewers are a good example, because there's just
too much code to know by heart).
And if we accept mFoo, then the stylistic
On Mon, Jul 06, 2015 at 08:12:36PM -0700, Jeff Gilbert wrote:
> I propose that we stop recommending the universal use of an 'a' prefix for
> arguments to functions in C and C++. If the prefix helps with
> disambiguation, that's fine. However, use of this prefix should not be
> prescribed in general
On 06/07/15 11:12 PM, Jeff Gilbert wrote:
> I propose that we stop recommending the universal use of an 'a' prefix for
> arguments to functions in C and C++. If the prefix helps with
> disambiguation, that's fine. However, use of this prefix should not be
> prescribed in general.
>
> `aFoo` does n
I propose that we stop recommending the universal use of an 'a' prefix for
arguments to functions in C and C++. If the prefix helps with
disambiguation, that's fine. However, use of this prefix should not be
prescribed in general.
`aFoo` does not provide any additional safety that I know of.[1] As
On Mon, Jul 6, 2015 at 7:52 AM, Ryan VanderMeulen
wrote:
>
> The tl;dr:
> Instead of only having binary "visible" or "hidden" states, we're adding a
> middle ground. A Tier 2 option is being added that allows for jobs that
> meet most but not all of the visibility requirements to be visible by
> d
On Mon, Jul 6, 2015 at 3:05 PM, Karl Tomlinson wrote:
> Vladan D. writes:
>
> > Should fixing shutdown hangs be higher priority?
>
> _exit() after profile-before-change notification would be the
> many-holes-with-one-plug bug to prioritize.
>
> https://wiki.mozilla.org/XPCOM_Shutdown
> https://bu
Vladan D. writes:
> Should fixing shutdown hangs be higher priority?
_exit() after profile-before-change notification would be the
many-holes-with-one-plug bug to prioritize.
https://wiki.mozilla.org/XPCOM_Shutdown
https://bugzilla.mozilla.org/show_bug.cgi?id=662444
_
On 06/07/2015 17:08, Marcello Stanisci wrote:
Alternatively, create an empty dialog and manipulate the dialog using DOM
based on the arguments you pass using window.open[Dialog](...). This is
What do you mean by 'empty dialog'? Is it a
a. xul "skeleton" file
This.
~ Gijs
__
We took it to the stre... IRC, and in result of that I filed to bugs:
1) https://www.w3.org/Bugs/Public/show_bug.cgi?id=28920
2) https://bugzilla.mozilla.org/show_bug.cgi?id=1180927
zb.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https:
Ah, right.
On 06/07/15 23:05, Vladan D wrote:
> I think you misunderstood, I wasn't talking about the reducing the watchdog
> timeout :)
> I was saying that shutdown hangs result in bad Crash Reporter UX, so that is
> one more reason to *fix* shutdown hangs, i.e. reduce the shutdown hang rate
>
On Monday, July 6, 2015 at 5:00:36 PM UTC-4, David Rajchenbach-Teller wrote:
> On 06/07/15 22:48, Vladan D wrote:
> > KaiRo pointed out another reason to reduce shutdown hang rates on IRC: it's
> > lousy UX. The crash-reporter dialog pops up a minute after the user closed
> > Firefox
>
>
> That
> Should fixing shutdown hangs be higher priority?
> And if so, should we allow features with shutdown hangs to be released?
I admit to skimming over shutdown-hang signatures when looking at
topcrash lists. In my experience they're often longstanding issues that
are difficult to diagnose and rare
On 06/07/15 22:48, Vladan D wrote:
> KaiRo pointed out another reason to reduce shutdown hang rates on IRC: it's
> lousy UX. The crash-reporter dialog pops up a minute after the user closed
> Firefox
That's bug 1137941, but how would that reduce shutdown hangs?
--
David Rajchenbach-Teller, P
On Mon, Jul 6, 2015 at 1:37 PM, Ryan VanderMeulen wrote:
> On 7/6/2015 4:34 PM, Vladan D wrote:
>
>> Background: Firefox shutdown hangs are turned into shutdown crashes by a
>> watchdog thread [1] that forces a crash if shutdown hasn't completed within
>> 1 minute. Thanks to the watchdog and the
KaiRo pointed out another reason to reduce shutdown hang rates on IRC: it's
lousy UX. The crash-reporter dialog pops up a minute after the user closed
Firefox
On Monday, July 6, 2015 at 4:37:41 PM UTC-4, RyanVM wrote:
> On 7/6/2015 4:34 PM, Vladan D wrote:
> > Background: Firefox shutdown hangs
>> Should fixing shutdown hangs be higher priority?
Starting and shutting down properly (and quickly), IMO, fall into the
"core quality" / "no compromise" / "we have to get this right" bucket.
So making it higher priority sounds aligned with the Three Pillars.
>> And if so, should we allow featu
On 7/6/2015 4:34 PM, Vladan D wrote:
Background: Firefox shutdown hangs are turned into shutdown crashes by a
watchdog thread [1] that forces a crash if shutdown hasn't completed within 1
minute. Thanks to the watchdog and the Windows profile unlocker [2], shutdown
hangs aren't as frustrating
Background: Firefox shutdown hangs are turned into shutdown crashes by a
watchdog thread [1] that forces a crash if shutdown hasn't completed within 1
minute. Thanks to the watchdog and the Windows profile unlocker [2], shutdown
hangs aren't as frustrating as they used to be. However, shutdown h
On Monday, July 6, 2015 at 12:48:33 PM UTC-7, smaug wrote:
> I don't know what "have a MO set on the document during readyState=loading"
> actually means.
Document has three loading states - loading, interactive, complete[0].
I'm initializing MO during loading stage, so that I have a chance to m
On 07/06/2015 10:33 PM, Zibi Braniecki wrote:
Hi all,
I have a question about MO behavior.
From what I understand, MutationObserver API is designed in a way that is
supposed to guarantee two things that I need:
1) That if I have a MO set on the document during readyState=loading, then all
co
Hi all,
I have a question about MO behavior.
>From what I understand, MutationObserver API is designed in a way that is
>supposed to guarantee two things that I need:
1) That if I have a MO set on the document during readyState=loading, then all
consequent elements injected by Parser into DOM
I suppose that the general problem is that we are using an nsRefPtr
lvalue in one side of the branch, and an nsRefPtr xvalue on the other
(as the nullptr is being cast to an nsRefPtr, which has to live in a
temporary making it an xvalue). This is reasonable in a situation where
we actually want
I think an API like:
window.navigator.addBusyTask(promise);
would be great. The API can be called any time and any number of
times. The API would run the spinner until all provided promises are
resolved. So if it's called twice with different promises, the spinner
doesn't stop when one of the pro
Looks good to me!
On Mon, Jul 6, 2015 at 10:52 AM, Ryan VanderMeulen
wrote:
> For a little over 2 years, our Job Visibility Policy has been in place to
> identify all the requirements necessary for a build or test suite to be
> visible in our infrastructure.
> https://wiki.mozilla.org/Sheriffing/
> Alternatively, create an empty dialog and manipulate the dialog using DOM
> based on the arguments you pass using window.open[Dialog](...). This is
What do you mean by 'empty dialog'? Is it a
a. xul "skeleton" file
or something like
b. openDialog("about:blank"); ?
I might have missed that, b
For a little over 2 years, our Job Visibility Policy has been in place to
identify all the requirements necessary for a build or test suite to be
visible in our infrastructure.
https://wiki.mozilla.org/Sheriffing/Job_Visibility_Policy
However, little has changed with the policy since TBPL was stil
Hi everyone,
You can find below the list of new issues found and filed by the Desktop
Manual QA team last week (Week 27: June 29 - July 03).
Additional details on the team's priorities last week, as well as the plans
for the current week can be found at:
https://etherpad.mozilla.org/Deskto
Use a data: URL, or failing that, define your own protocol handler and
use that to return the XUL DOM you want, when used with openDialog.
Alternatively, create an empty dialog and manipulate the dialog using
DOM based on the arguments you pass using window.open[Dialog](...). This
is probably
Hello,
Consider the method: window.openDialog(URL.xul, ...). Its final result
is to opens a dialog from the content read in file URL.xul.
After some web surfing, it seems not possible to programmatically
define a dialog, and then open that dialog (somehow) from the main window.
So, in the contex
Michael Layzell wrote:
In summary, the nsRefPtr is copied into a temporary in its side of the
conditional. The nullptr is cast to a struct Foo*, which is constructed into a
nsRefPtr, which is bound to a temporary, and then moved around a bit between
temporaries. The resulting temporary xvalue
Ok, I solved the issue for my case. The problem was the evaluation method: in
window (normal security context, not working) or as chrome (chrome security
context, working!).
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozi
Yes, v31.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
On Mon, Jul 6, 2015 at 3:22 AM, Mike Connor wrote:
> Anne, I assume the point is not to draw attention to background tabs. There
> are much more useful ways to do that, if they're going to ask for a new
> API/UI. Instead, my read is that they're looking for a hopefully-not-janky
> busy indicator
On 06/07/2015 03:22 , Mike Connor wrote:
Does it need to be an API, or would dispatching an event be sufficient?
Something like "busy" and "idle" events would be easy to send from JS, and
UAs would be free to honour or ignore based on context.
On the face of it it's certainly useful: writing yo
40 matches
Mail list logo
