As someone pushing for the ScreenOrientation API, I agree with this
intent nonetheless.
It *might* be worth warning about this property being inconsistent,
and that it's better for users to use the ScreenOrientation API. But I
think it's really only worth doing if this is something that other
brow
*Summary*: window.orientation returns a value corresponding to the screen
orientation. The orientationchange event is fired when the orientation of
the viewport is changed. These features are non-standard but have been
implemented by other browser vendors on mobile platforms leading to
widespread u
On 10/19/15 4:07 PM, Gregory Szorc wrote:
Or you could register a custom content type handler (possibly via a special
"Gecko Hackers" Firefox add-on) that runs an appropriate mach command when
said file is downloaded.
This ignores the point about running the file after downloading having
diffe
On Tue, Oct 20, 2015 at 1:18 AM, Ms2ger wrote:
> Please submit tests to web-platform-tests and create a pull request to
> the HTML standard.
>
Will do, after a decent interval to collect feedback. I wrote
web-platform-tests to land with our implementation.
Rob
--
lbir ye,ea yer.tnietoehr rdn
>
> Also, .h dependency proliferation is a real problem for build system
> performance, especially with the autogenerated mozilla-include.h (which
> contains things from every AC_DEFINE in configure.in - an add AC_DEFINE,
> invalidate everything). If you build the tips of mozilla-central from 24h
>
On Mon, Oct 19, 2015 at 11:47 AM, Bobby Holley
wrote:
> On Mon, Oct 19, 2015 at 8:20 AM, Josh Matthews
> wrote:
>
> > On 2015-10-19 1:17 AM, Bobby Holley wrote:
> >
> >> I've heard two compelling arguments against the current setup:
> >> (1) It's inconsistent.
> >> (2) It causes unnecessary over
On Sat, Oct 17, 2015 at 3:48 PM, Ben Kelly wrote:
> On Oct 16, 2015 6:17 PM, "Robert O'Callahan" wrote:
> > I guess the right fix would be to have a Web proxy service that accepts
> > URLs in a custom format, unpacks ZIP files and serves their contents.
>
> Bugzilla could do this in a service wo
On Mon, Oct 19, 2015 at 8:20 AM, Josh Matthews
wrote:
> On 2015-10-19 1:17 AM, Bobby Holley wrote:
>
>> I've heard two compelling arguments against the current setup:
>> (1) It's inconsistent.
>> (2) It causes unnecessary overhead when you do |mach build foo bar|
>> because
>> we link between foo
I am removing the "nsDebug" logger [1] in bug 1215629 [2]. It was added some 12
years ago and the purpose has seemingly been lost over the years.
If you happen to rely on this being available please let us know. If I don't
hear any strong objections in the next day I will land the removal patch.
On 16/10/2015 08:15, Mike Hommey wrote:
> There are however now two build targets that can do the right thing for
> most use cases:
> - mach build binaries, which will build C/C++ related things
> appropriately
> - mach build faster, which will build JS, XUL, CSS, etc. (iow, non
> C/C++) (alth
On 10/19/15 12:46 PM, Anne van Kesteren wrote:
On Mon, Oct 19, 2015 at 6:36 PM, Boris Zbarsky wrote:
Summary: The web more or less depends on one of the prefixed versions of
matchesSelector (being implemented).
I think you mean matches() is being implemented, while the web depends
on a prefix
On Mon, Oct 19, 2015 at 6:36 PM, Boris Zbarsky wrote:
> Summary: The web more or less depends on one of the prefixed versions of
> matchesSelector (being implemented).
I think you mean matches() is being implemented, while the web depends
on a prefixed version of matchesSelector(). matches() and
Summary: The web more or less depends on one of the prefixed versions of
matchesSelector (being implemented). We might as well implement the
webkit one and drop the moz one.
Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1216193
Standard: https://dom.spec.whatwg.org/#dom-element-webkitmatc
On 10/18/2015 10:17 PM, Bobby Holley wrote:
On Sun, Oct 18, 2015 at 8:37 PM, Boris Zbarsky wrote:
On 10/18/15 7:14 PM, Nicholas Nethercote wrote:
Eventually |mach build| should just do the right
thing, no matter what files you've touched...
The problem is that definitions of "right thing"
On 2015-10-19 4:28 AM, Nicholas Nethercote wrote:
On Sun, Oct 18, 2015 at 8:37 PM, Boris Zbarsky wrote:
Eventually |mach build| should just do the right
thing, no matter what files you've touched...
The problem is that definitions of "right thing" differ depending on the
goal, right?
I'm u
On 2015-10-19 1:17 AM, Bobby Holley wrote:
I've heard two compelling arguments against the current setup:
(1) It's inconsistent.
(2) It causes unnecessary overhead when you do |mach build foo bar| because
we link between foo and bar.
I don't recall reading (2) in this thread, and it certainly w
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/19/2015 06:02 AM, Robert O'Callahan wrote:
> https://bugzilla.mozilla.org/show_bug.cgi?id=264412
>
> Webkit, Blink and Trident have been shipping this for years without
> a spec and with poor interop. We held off on implementing it since
> you c
On Sun, Oct 18, 2015 at 8:37 PM, Boris Zbarsky wrote:
>>
>> Eventually |mach build| should just do the right
>> thing, no matter what files you've touched...
>
> The problem is that definitions of "right thing" differ depending on the
> goal, right?
I'm using the standard build system sense of "r
Hi everyone,
Here's the list of new issues found and filed by the Desktop Manual QA
team last week (Week 42: October 12 - October 16).
Additional details on the team's priorities last week, as well as the
plans for the current week are available at:
https://public.etherpad-mozilla.org/p/
19 matches
Mail list logo
