On Mon, Jul 6, 2015 at 3:22 AM, Mike Connor mcon...@mozilla.com 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
Yes, v31.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
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
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 your
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
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 features with
On Mon, Jul 6, 2015 at 1:37 PM, Ryan VanderMeulen rya...@gmail.com 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
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, PhD
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
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
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
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
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
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's bug
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
Looks good to me!
On Mon, Jul 6, 2015 at 10:52 AM, Ryan VanderMeulen
rvandermeu...@mozilla.com 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.
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
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
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
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
On Mon, Jul 6, 2015 at 7:52 AM, Ryan VanderMeulen
rvandermeu...@mozilla.com 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
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
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 Mon, Jul 6, 2015 at 3:05 PM, Karl Tomlinson mozn...@karlt.net 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
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
by
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
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]
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.
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
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
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 not
On Tue, Jul 7, 2015 at 3:26 PM, Mike Hommey m...@glandium.org 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
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 rob...@ocallahan.org
wrote:
On Tue,
I like 'aFoo'.
Nick
On Tue, Jul 7, 2015 at 1:12 PM, Jeff Gilbert jgilb...@mozilla.com 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
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
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, but
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
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:
38 matches
Mail list logo
