On Wednesday 2014-07-02 10:05 +0300, Henri Sivonen wrote:
> On Tue, Jul 1, 2014 at 10:58 PM, Koji Ishii wrote:
> > Platform coverage: all platforms (parsing only, layout will be in separate
> > intents)
>
> The parsing change is the easy part. Is there a plan to get the layout
> part implemented
Google docs is a very good use case, In a previous job I implemented a web
based spreadsheet and we also had to implement our own contextmenu and
surpress the default because of the way that it conflicts.
Its a catch 22, applications will continue to hijack the default menu
unless the functionalit
On 2014-07-02, 4:16 PM, Dao wrote:
On 02.07.2014 20:51, Ehsan Akhgari wrote:
We can still show the UA
context menu if you hold down shift like we do today though.
What would be the equivalent to that on Firefox OS?
I don't think we have a similar way to do this in Firefox OS.
Cheers,
Ehsan
On 02.07.2014 20:51, Ehsan Akhgari wrote:
We can still show the UA
context menu if you hold down shift like we do today though.
What would be the equivalent to that on Firefox OS?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://li
On 2014-07-02 14:51, Ehsan Akhgari wrote:
> On 2014-07-02, 2:36 PM, Wesley Hardman wrote:
>> The current context menu event does suffer from the same issue. If this is
>> implemented, there at least needs to be a matching
>> dom.event.contextmenu.showall preference to always show all menu items.
On 2014-07-02, 2:55 PM, Wesley Hardman wrote:
That doesn't work if you have Element Inspector installed
(https://addons.mozilla.org/en-US/firefox/addon/element-inspector/). It is
restart-less, so I suppose its easy to toggle on and off.
Add-ons which hijack our key bindings cause all sorts o
That doesn't work if you have Element Inspector installed
(https://addons.mozilla.org/en-US/firefox/addon/element-inspector/). It is
restart-less, so I suppose its easy to toggle on and off.
On 2014-07-02 14:49, Jan Varga wrote:
> Just FYI, the current implementation in Gecko also checks the sh
On 2014-07-02, 2:36 PM, Wesley Hardman wrote:
The current context menu event does suffer from the same issue. If this is
implemented, there at least needs to be a matching
dom.event.contextmenu.showall preference to always show all menu items.
I don't think this proposal is worse, but it isn'
Just FYI, the current implementation in Gecko also checks the shift key,
if it is pressed then custom context menu items won't show at all, just
the UA items.
On 02/07/14 14:36, Wesley Hardman wrote:
The current context menu event does suffer from the same issue. If this is
implemented, ther
The current context menu event does suffer from the same issue. If this is
implemented, there at least needs to be a matching
dom.event.contextmenu.showall preference to always show all menu items.
I don't think this proposal is worse, but it isn't really better. With the
current event, I alw
On 7/2/2014 12:01 PM, Gregory Szorc wrote:
On 7/2/14, 9:48 AM, Gijs Kruitbosch wrote:
On 02/07/2014 17:46, Joshua Cranmer 🐧 wrote:
On 7/2/2014 11:18 AM, Gregory Szorc wrote:
I find the current state extremely frustrating. I had big plans for
the in-tree docs, including capturing JavaScript doc
On 7/2/14, 9:48 AM, Gijs Kruitbosch wrote:
On 02/07/2014 17:46, Joshua Cranmer 🐧 wrote:
On 7/2/2014 11:18 AM, Gregory Szorc wrote:
I find the current state extremely frustrating. I had big plans for
the in-tree docs, including capturing JavaScript docs and having JSM
APIs automatically publishe
On 7/2/2014 11:18 AM, Gregory Szorc wrote:
I find the current state extremely frustrating. I had big plans for
the in-tree docs, including capturing JavaScript docs and having JSM
APIs automatically published to MDN so we don't have to write docs
twice. If anyone is in a position to nudge this
On 02/07/2014 17:46, Joshua Cranmer 🐧 wrote:
On 7/2/2014 11:18 AM, Gregory Szorc wrote:
I find the current state extremely frustrating. I had big plans for
the in-tree docs, including capturing JavaScript docs and having JSM
APIs automatically published to MDN so we don't have to write docs
twic
I've written a cross-platform file watching API for Windows/OS X/Linux
before. It's no fun.
I would strongly recommend using an existing higher-level abstraction
layer because implementing this ourselves will lead to constant edge
case discovery and bug fixing. I'd like to think that any reaso
(I meant to loop in m.d.platform originally, but the message seems to
have gotten lost in the void)
On 01/07/2014 20:14, Gijs Kruitbosch wrote:
(Followup/reply-to: m.tools.bmo / tools-bmo@lists.m.o)
For a little over half a year now, I've been following new bugs filed in
Firefox::Untriaged fro
On 7/2/14, 4:21 AM, Mike Hommey wrote:
On Wed, Jul 02, 2014 at 12:43:47PM +0200, Axel Hecht wrote:
On 7/2/14 12:25 PM, Yonggang Luo wrote:
I am using Mozilla XUL SDK to build my own application, So I'd like
to know what's the format of jar.mn file
Took me a while to find it, but I think that
On 02.07.2014 17:30, Ehsan Akhgari wrote:
On 2014-07-02, 3:12 AM, Henri Sivonen wrote:
On Sun, Jun 29, 2014 at 4:53 AM, Dale Harvey wrote:
we are
looking to implement an optional attribute that allows authors to
disable
the default context menu items so only the applications items are shown.
On 2014-07-02, 3:12 AM, Henri Sivonen wrote:
On Sun, Jun 29, 2014 at 4:53 AM, Dale Harvey wrote:
we are
looking to implement an optional attribute that allows authors to disable
the default context menu items so only the applications items are shown.
I think we shouldn't do this, since it wou
According to the manpage of fanotify, « there is no support for create,
delete, and move events, » which would make it useless for our scenario.
What kind of drawbacks are you talking about in the case of inotify? The
possible race condition that [1] attempts to solve?
Are there any build incanta
On Wed, Jul 02, 2014 at 01:41:54PM +0200, David Rajchenbach-Teller wrote:
> The main usecase is an editor that needs to 1/ reload resources when
> they have been modified by an outside application; 2/ see when resources
> are added or removed.
>
> In other words, watching a directory (recursively)
Hello :-),
On 02/07/2014 13:41, David Rajchenbach-Teller wrote:
Which library do you suggest?
libuv also allows to watch a FS, whatever the platform:
https://github.com/joyent/libuv.
Cheers.
--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/
PhD. student at DISC/Femto-ST (Vesontio) a
On Wed, Jul 02, 2014 at 02:23:51PM +0200, Dirkjan Ochtman wrote:
> On Wed, Jul 2, 2014 at 1:41 PM, David Rajchenbach-Teller
> wrote:
> > Which library do you suggest?
>
> Take a look at watchman:
>
> https://github.com/facebook/watchman
That one uses inotify as well. Might as well use glib.
Mi
On Wed, Jul 2, 2014 at 1:41 PM, David Rajchenbach-Teller
wrote:
> Which library do you suggest?
Take a look at watchman:
https://github.com/facebook/watchman
Cheers,
Dirkjan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.m
On 02/07/14 17:05, Henri Sivonen wrote:
On Tue, Jul 1, 2014 at 10:58 PM, Koji Ishii wrote:
Platform coverage: all platforms (parsing only, layout will be in separate
intents)
The parsing change is the easy part. Is there a plan to get the layout
part implemented?
My general take on this iss
The main usecase is an editor that needs to 1/ reload resources when
they have been modified by an outside application; 2/ see when resources
are added or removed.
In other words, watching a directory (recursively) for add/remove/modify
changes to files.
Which library do you suggest?
Cheers,
Da
On Wed, Jul 02, 2014 at 12:43:47PM +0200, Axel Hecht wrote:
> On 7/2/14 12:25 PM, Yonggang Luo wrote:
> >I am using Mozilla XUL SDK to build my own application, So I'd like
> >to know what's the format of jar.mn file
> >
>
> Took me a while to find it, but I think that
> https://ci.mozilla.org/job
On Wed, Jul 02, 2014 at 12:13:44PM +0200, David Rajchenbach-Teller wrote:
> For its recently landed WebIDE, the devtools team needs a component to
> watch changes in a directory (they are currently using a somewhat
> hackish workaround that they want to replace with something better
> supported). B
On 7/2/14 12:25 PM, Yonggang Luo wrote:
I am using Mozilla XUL SDK to build my own application,
So I'd like to know what's the format of jar.mn file
Took me a while to find it, but I think that
https://ci.mozilla.org/job/mozilla-central-docs/Tree_Documentation/buildsystem/jar-manifests.html
I am using Mozilla XUL SDK to build my own application,
So I'd like to know what's the format of jar.mn file
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
For its recently landed WebIDE, the devtools team needs a component to
watch changes in a directory (they are currently using a somewhat
hackish workaround that they want to replace with something better
supported). Both Windows and MacOS X provide built-in functions for this
purpose but most Unice
On Sun, Jun 29, 2014 at 4:53 AM, Dale Harvey wrote:
> we are
> looking to implement an optional attribute that allows authors to disable
> the default context menu items so only the applications items are shown.
I think we shouldn't do this, since it would be hostile to users. I
think it would be
On Tue, Jul 1, 2014 at 10:58 PM, Koji Ishii wrote:
> Platform coverage: all platforms (parsing only, layout will be in separate
> intents)
The parsing change is the easy part. Is there a plan to get the layout
part implemented?
My general take on this issue is:
1) As far as assigning the time
33 matches
Mail list logo
