Tiling is in a usable state (modulo some reftest failures), but I
haven't tried to run talos with tiling enabled yet. We'll probably see
the benefit of tiling when we enable APZ (which I don't know the state
of on Linux). We can also enable OMTA but I haven't tried to run tests
with it or dogfood
Congratulations to all!
This sounds like a massive improvement to our rendering pipeline, definitely
worth of some PR effort! Is that being considered?
Is this expected to have an impact on Talos numbers? I’d expect them to
improve, but that probably also depends on the hardware used for the
On 3/12/15 5:39 AM, Chris Pearce wrote:
Breaking VisualStudio Intellisense also broke most of the code
navigation things that make VisualStudio awesome.
Chris,
So just to make sure the actual question in Nathan's mail is answered:
1) You're saying Intellisense _does_ work in a reasonable
On 3/12/15 12:26, Aryeh Gregor wrote:
Because unless things have changed a lot in the last three years or
so, HTTPS is a pain for a few reasons:
1) It requires time and effort to set up. Network admins have better
things to do. Most of them either are volunteers, work part-time,
computers
On 3/12/15 6:28 AM, Anne van Kesteren wrote:
It does seem like there are some improvements we could make here. E.g.
not allow an iframe to request certain permissions. Insofar we
haven't already.
That doesn't help much; the page can just navigate itself to the attack
site instead of loading
On 2015-03-12 8:26 AM, Aryeh Gregor wrote:
Aha, that makes a lot more sense. Thanks. Yes, that does seem like a
more realistic attack. A few points come to mind:
1) The page has no way to know whether it has persisted permissions
without just trying, right? If so, the user will notice
On 2015-03-12 9:45 AM, Boris Zbarsky wrote:
On 3/12/15 6:28 AM, Anne van Kesteren wrote:
It does seem like there are some improvements we could make here. E.g.
not allow an iframe to request certain permissions. Insofar we
haven't already.
That doesn't help much; the page can just navigate
On 3/12/15 10:26 AM, Ehsan Akhgari wrote:
Well, top level navigation cancels the fullscreen mode, right?
The attack scenario I'm thinking is:
1) User loads http://a.com
2) Attacker immediately sets location to http://b.com
3) Attacker's hacked-up b.com goes fullscreen, pretending to still be
On 2015-03-12 11:24 AM, Boris Zbarsky wrote:
On 3/12/15 10:26 AM, Ehsan Akhgari wrote:
Well, top level navigation cancels the fullscreen mode, right?
The attack scenario I'm thinking is:
1) User loads http://a.com
2) Attacker immediately sets location to http://b.com
3) Attacker's hacked-up
On 3/12/15 12:19 PM, Ehsan Akhgari wrote:
(Note that the
fullscreen API cannot be used outside of user generated event handlers.)
Oh, good point. That helps a lot, yes.
-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
On 2015-03-12 12:57 PM, Boris Zbarsky wrote:
On 3/12/15 12:19 PM, Ehsan Akhgari wrote:
(Note that the
fullscreen API cannot be used outside of user generated event handlers.)
Oh, good point. That helps a lot, yes.
So do you think it makes sense to restrict iframes requesting certain
Hello dev-platform,
I recently joined the DOM team as an embedded QA member. One of the
things I've been working on is establishing and documenting QA
processes. I have two goals with this effort:
1. To make it clear how volunteers can help
2. To make it clear how developers and QA can help
On Thu, Mar 12, 2015 at 12:31 PM, Aryeh Gregor a...@aryeh.name wrote:
On Thu, Mar 12, 2015 at 4:34 PM, Ehsan Akhgari ehsan.akhg...@gmail.com
wrote:
2) If the only common real-world MITM threat is via a compromise
adjacent to the client (e.g., wireless), there's no reason to restrict
Hi Mike,
This sounds like a massive improvement to our rendering pipeline, definitely
worth of some PR effort! Is that being considered?
We’ve had a PR effort before when Silk landed on b2g. It hit hacker news and
received over 10K views IIRC on mozilla hacks, so I’m not keen on doing
On 3/12/15 3:31 PM, Aryeh Gregor wrote:
2) Attacker opens a background tab and navigates it to http://b.com (I
can't think of a JavaScript way to do this, but if there isn't one,
making a big a href=b.com target=_blank that covers the whole page
would work well enough)
This is presuming user
On 11/03/15 18:12, Mason Chang wrote:
Project Silk (http://www.masonchang.com/blog/2015/1/22/project-silk),
which aligns rendering to vsync, will be landing over the next couple
of weeks (bug 1071275). You should expect smoother animations and
scrolling while browsing the web. It'll land in 4
On Thu, Mar 12, 2015 at 4:34 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote:
2) If the only common real-world MITM threat is via a compromise
adjacent to the client (e.g., wireless), there's no reason to restrict
geolocation, because the attacker already knows the user's location
fairly
On Thu, Mar 12, 2015 at 2:56 PM, Adam Roach a...@mozilla.com wrote:
As an aside, the first three are not just fixable, but actually fixed within
the next few months: https://letsencrypt.org/
Indeed, and for performance concerns there's a good read here:
https://istlsfastyet.com/ It's no longer
On 3/12/15 1:28 PM, Ehsan Akhgari wrote:
Another concern with persisting permissions requested from iframes
Can we persist them for the pair (origin of iframe, origin of toplevel
page) or something?
-Boris
___
dev-platform mailing list
On Fri, Mar 13, 2015 at 12:34 PM, Seth Fowler s...@mozilla.com wrote:
I guess (but don’t know for sure) that recording RR data for every test
that gets run might be too expensive.
It probably wouldn't be too expensive. The runtime overhead is low; the
main cost is trace storage, but we can
I thought I’d let everyone know that bug 1142366 and bug 1142376 have added
some handy new features to mozilla::Pair. In particular:
- Pair objects are now movable. (It’s now a requirement that the underlying
types be movable too. Every existing use satisfied this requirement.)
- Pair objects
Chrome removed support for multipart/x-mixed-replace main resources in this
issue:
https://code.google.com/p/chromium/issues/detail?id=249132
https://code.google.com/p/chromium/issues/detail?id=249132
Here’s their explanation:
This feature is extremely rarely used by web sites and is the
Intellisense and other code navigation things all work now in the generated
project file. This is awesome, thanks!
Chris Pearce.
On Friday, March 13, 2015 at 10:13:55 AM UTC+13, Nathan Froyd wrote:
On Thu, Mar 12, 2015 at 5:39 AM, Chris Pearce cpea...@mozilla.com wrote:
Breaking
Yeah it is, but I don’t really want to do another PR run when lots of people
have already read about Silk on b2g. Feels spammy to me to do another one just
a month after the previous one, but that’s my 2 cents.
Mason
On Mar 12, 2015, at 3:17 PM, Robert O'Callahan rob...@ocallahan.org wrote:
The A-Team is embarking on a project to improve the developer experience
when running unittests locally. This project will address the following
frequently-heard complaints:
* Locally developers often use mach to run tests, but tests in CI use
mozharness, which can result in different behaviors.
I've been meaning to rip out the putative support for this from XHR (and
all of the complexity that it introduces) for months now. This would be
great.
- Kyle
On Thu, Mar 12, 2015 at 3:37 PM, Seth Fowler s...@mozilla.com wrote:
Chrome removed support for multipart/x-mixed-replace main
On Fri, Mar 13, 2015 at 11:59 AM, Mason Chang mch...@mozilla.com wrote:
Yeah it is, but I don’t really want to do another PR run when lots of
people have already read about Silk on b2g. Feels spammy to me to do
another one just a month after the previous one, but that’s my 2 cents.
I see,
On Tue, Mar 10, 2015 at 5:00 PM, Boris Zbarsky bzbar...@mit.edu wrote:
The mitigation applies in this situation:
1) User connects to a MITMed network (e.g. wireless at the airport or
coffeeshop or whatever) which I will henceforth call the attacker.
2) No matter what site the user
IME the issue is not so much about not running tests identical to the
ones on CI, but the OS environment which doesn't match, and then
reproducing intermittent failures.
If a failure happens once in 100 builds, it is very annoying for the
sheriffs (happens multiple times a day) and needs
On 3/12/15 7:04 PM, Seth Fowler wrote:
It looks like it doesn’t anymore, because it works fine in Chrome.
Iirc, bugzilla sniffs server-side and sends different things to
different browsers. Worth testing in Firefox with multipart/x-mixed
support disabled.
-Boris
On 2015-03-12 6:54 PM, Kyle Huey wrote:
I've been meaning to rip out the putative support for this from XHR (and
all of the complexity that it introduces) for months now. This would be
great.
Henri beat you by two years. ;-)
https://bugzilla.mozilla.org/show_bug.cgi?id=843508
Every time I break something that doesn't have a mach command (such as
various Gaia tests for example) I shiver in fear, as I need to download
the log, read it pretty much line by line and try to retrace
mozharnesses' steps along the way. Is the runtests tool also going to
help with those
I wonder if it is possible to trigger particular single unittest on which
we observe intermittent failures, instead of the whole test set. I guess it
would save time. I sometimes disable all tests I do not need to check
before pushing to the try to make it end faster.
- Xidorn
On Fri, Mar 13,
On 3/12/15 6:37 PM, Seth Fowler wrote:
They made main resources that use multipart/x-mixed-replace trigger downloads
instead of being displayed.
So what gets downloaded is the entire mixed stream, right?
The observation that multipart/x-mixed-replace support introduces a lot of
complexity
On 2015/03/13 7:51, Jonathan Griffin wrote:
The A-Team is embarking on a project to improve the developer experience
when running unittests locally.
Is this about C++ unittests or about mochitests etc.?
If it's the latter, most of my pain points would be around debugging B2G
failures.
On 3/12/15 6:51 PM, Jonathan Griffin wrote:
What other use cases would you like us to address, which aren't derivatives
of the above issues?
I ran into a problem just yesterday: I wanted to run mochitest-browser
locally, to debug an error that happened very early in the test run startup.
So
To build off this idea, I'd like a run-until-failure mode (with an upper
limit, of course) on try itself. I don't want to spend N+ hours spinning my
CPU locally to repro an intermittent. I also don't want to wait until a
build is done to press the retrigger button 40 times.
My blue-sky wish would
Within the small circle of Mozilla contributors it may feel spammy or
repetitive, but I wouldn't be surprised for people outside of the Mozilla
project to think of b2g and Firefox desktop as both separate userbases and
separate impacts.
On Thu, Mar 12, 2015 at 6:59 PM, Mason Chang
On Fri, Mar 13, 2015 at 01:50:33PM +1300, Robert O'Callahan wrote:
On Fri, Mar 13, 2015 at 12:34 PM, Seth Fowler s...@mozilla.com wrote:
I guess (but don’t know for sure) that recording RR data for every test
that gets run might be too expensive.
It probably wouldn't be too expensive.
On Tuesday, March 10, 2015 at 2:38:43 PM UTC, Ehsan Akhgari wrote:
Have you tested bumping the gcc min version here
http://mxr.mozilla.org/mozilla-central/source/build/autoconf/toolchain.m4#104
to see if there are any builders that still use gcc 4.6?
I haven't, no.
I assume you mean by
40 matches
Mail list logo
