On 2015-08-17 7:21 PM, Kartikaya Gupta wrote:
FWIW one of the original driver behind Eideticker (tuning Fennec for
checkerboarding during scrolling) will become relevant again in the
next couple of months as we transition Fennec to using the C++ APZ
code and off the old Java pan/zoom code. While
FWIW one of the original driver behind Eideticker (tuning Fennec for
checkerboarding during scrolling) will become relevant again in the
next couple of months as we transition Fennec to using the C++ APZ
code and off the old Java pan/zoom code. While it would be nice to
have Eideticker around to gi
I don’t know about overall quality - seems the (very subjective) same to me. I
use it all day, every day and rarely run into problems.
> On Aug 17, 2015, at 3:14 PM, Dirkjan Ochtman wrote:
>
> 4. 1193977 -- HTML video is rendered on top of the title bar on OS X
This one I've seen a number of t
The Eideticker project (http://eideticker.mozilla.org) was started
almost 4 years ago, in an effort to better measure the performance of
Firefox for Android by directly capturing video of the browser
performing various actions. It later evolved to encompass testing
FirefoxOS performance. It's an
Yay!
On Mon, Aug 17, 2015 at 1:55 PM, William Chen wrote:
> Summary: The Screen Orientation API provides the ability to read the screen
> orientation type and angle, to be informed when the screen orientation
> state changes, and be able to lock the screen orientation to a specific
> state. We ha
Summary: The Screen Orientation API provides the ability to read the screen
orientation type and angle, to be informed when the screen orientation
state changes, and be able to lock the screen orientation to a specific
state. We have been shipping an experimental version of this API with the
moz pr
Hi all,
I have an anecdote, and was wondering if others can corroborate: it
seems to me that Nightly's quality has been getting worse recently
(this is on latest OS X, rMBP). I'm specifically talking about the
past two to three weeks, where I was on holiday and as such spent less
time in Firefox t
As others have said, XUL is going away.
It is not going away tomorrow.
We should be careful about if and how we invest here, so usecases are
important.
On 15/08/2015 20:48, Philip Chee wrote:
Use case 1:
chrome://foo/content/bar.xul?a=b&c=d
This could be written as
chrome://foo/content/bar
On 16/08/2015 19:56, Neil wrote:
Can we revisit this in 2015 to see if the original reason still holds?
Well, we want to get rid of XUL. I'm not sure it makes much sense to
revisit any of its design decisions at this point.
Then why don't you object to bug 1034999?
Because it solved a concr
TL;DR: returning nsRefPtr/RefPtr from functions is now safer, assuming
appropriate compiler support. Go forth and experiment with returning such
values, and comment at [4] if you have issues with passing nsRefPtr/RefPtr
return values into functions that expect raw pointers.
Hi all,
People have h
On 17/08/2015 00:53, Adam Moore wrote:
> Seems like this has more to do with the overlay system than XUL
> itself. Losing the ability to add overlays to customize the browser
> chrome would be brutal, and a move away from XUL shouldn't be done at
> the expense of what the ecosystem provides today f
On 17 August 2015 at 20:06, Philip Chee wrote:
> On 17/08/2015 02:56, Neil wrote:
> > Philip Chee wrote:
> >
> >> The first question that occurs to me is what is the rationale? Can
> >> we revisit this in 2015 to see if the original reason still holds?
> >>
> > Back then ignoring the hash or the
On 17/08/2015 02:56, Neil wrote:
> Philip Chee wrote:
>
>> The first question that occurs to me is what is the rationale? Can
>> we revisit this in 2015 to see if the original reason still holds?
>>
> Back then ignoring the hash or the search were equally complicated;
> nowadays ignoring the has
On 16/08/2015 13:31, Anne van Kesteren wrote:
> On Sat, Aug 15, 2015 at 9:48 PM, Philip Chee wrote:
>> The first question that occurs to me is what is the rationale? Can we
>> revisit this in 2015 to see if the original reason still holds?
>
> Well, we want to get rid of XUL. I'm not sure it make
On Mon, Aug 17, 2015 at 10:43 AM, Manuel Reimer
wrote:
> Is there some simple, efficient way to detect this case?
>
> I already tried "document.body.contains" but this didn't do the trick for
> me.
>
That (or just document.contains) should work. Please post a reduced
testcase if it doesn't.
>
Thank you for the information.
Is there some simple, efficient way to detect this case?
I already tried "document.body.contains" but this didn't do the trick
for me.
Or is it better to just ignore this (maybe pretty rare) case and handle
"detached trees" just like they would still be connect
The behavior here should be the same whether or not you're using
XrayWrappers: If you remove the parent, you'll end up with a detached
subtree. You can modify this subtree, but most of the operations (like
loading a web page in an iframe) will only matter when the page gets
reinserted into the docu
Hello,
maybe someone here can explain some details about the internals of
Firefox to me.
My addon "EmbedUpdater" replaces and tags with an
, when possible and a known replacement exists. This helps to
get rid of Flash.
Currently I have some more or less ugly "error handling" code to catc
I am looking forward of it.
--
此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Hi everyone,
You can find below the list of new issues found and filed by the Desktop
Manual QA team last week (Week 33: August 10 - August 14).
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/De
On Sat, Aug 15, 2015 at 5:49 AM, L. David Baron wrote:
> I guess I have mixed feelings about that. It's advantageous to have
> WHATWG specifications published under the W3C patent policy by this
> working group, though that doesn't require technical work happening
> in W3C.
For most specificatio
21 matches
Mail list logo
