Le 10 juil. 2014 à 14:57, Jonas Sicking a écrit :
> Many website use this feature to replace the UA context menu with
> their own context menu implemented in HTML. The result is a context
> menu which is less accessible. It also results in that if the user
> uses UA features to *not* make the UA
On Wed, Jul 2, 2014 at 9:14 AM, Dao wrote:
> 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
disabl
On Mon, Jun 30, 2014 at 5:26 AM, Wesley Hardman wrote:
> Suppressing the contextmenu is extremely user-hostile (for some users).
> There is a reason I always run with dom.event.contextmenu.enabled set to
> false.
This option would continue to work and make us ignore the
chrome="disabled" attri
On Sat, Jun 28, 2014 at 9:30 PM, Ian Hickson wrote:
> On Sat, 28 Jun 2014, Dale Harvey wrote:
>>
>> Application developers have the ability to specify additional menuitems for
>> contextmenus via
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#context-menus
On 7/9/14, 8:21 PM, Yonggang Luo wrote:
In the moz.build files, there is specified XPCSHELL_TESTS_MANIFESTS,
but I can not found where to processing this variable/files in mozbuild system.
See the following:
https://hg.mozilla.org/mozilla-central/file/fc35681b0a87/python/mozbuild/mozbuild/fron
I've recently been using gtest for media code. However I've come across
the issue of fopen() working locally but not on the try servers.
https://tbpl.mozilla.org/?tree=Try&rev=11d9f94c54bd
Any suggestions on how I should do this differently?
Anthony
__
In the moz.build files, there is specified XPCSHELL_TESTS_MANIFESTS,
but I can not found where to processing this variable/files in mozbuild system.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platfo
That is an unsupported way to use beta. Please use the download links below.
http://www.mozilla.org/en-US/firefox/beta/all/
https://www.mozilla.org/en-US/thunderbird/all-beta.html
On Jul 9, 2014 5:10 PM, "Tobias B. Besemer"
wrote:
> Hi!
>
> I was interested to test the new TB 31 Beta ...
> ...
Am Mittwoch, 9. Juli 2014 22:56:42 UTC+2 schrieb Benjamin Smedberg:
> On 7/9/2014 4:46 PM, Robert Kaiser wrote:
> > Most probably would not type a comment when they're not immediately
> > prompted for it. We could do an experiment around it, but I'd be
> > surprised if anything else comes out of
Hi!
I was interested to test the new TB 31 Beta ...
... I'm now using 24.6.0 ...
... so I installed the extension "Update Channel Selector 1.6" and switched to
"beta" ...
When I now open the "About" I see that I be on "beta", but TB says:
"Thunderbird is up to date" (I think there is a point at t
On 7/9/2014 4:46 PM, Robert Kaiser wrote:
Most probably would not type a comment when they're not immediately
prompted for it. We could do an experiment around it, but I'd be
surprised if anything else comes out of it.
There's no reason to guess or use personal anecdotes for this. We'll do
e
Most probably would not type a comment when they're not immediately
prompted for it. We could do an experiment around it, but I'd be
surprised if anything else comes out of it.
I for myself probably wouldn't type a comment myself in >90% of the
cases when that was required, and I know how helpfu
Hey all,
here’s an illustrative video of the last option that David mentioned.
http://cl.ly/2E0q3W3Y2S3h
Note in particular, that the restoring of the background windows is not
animated.
— Philipp
On 07 Jul 2014, at 06:43, David Rajchenbach-Teller wrote:
> (Cc-ing Philipp Sackl, for UX fee
As glob noted upthread, the NEW/ASSIGNED distinction is sometimes used
by people when they are the assignee. There is only a lack of difference
when the assignee is "nob...@mozilla.org". That doesn't warrant
abolishing the status (although we could arguably ask bmo folks to make
the "reset the
What’s the purpose of the “ASSIGNED" status? If we’re saying that this status
can be computed from Assigned To field (being set to nobody or something else),
then why do we still have it? If it isn’t equivalent, then we may be losing
some information if we reset it back to New.
--
- Milan
On
On 07/09/2014 08:33 AM, Gijs Kruitbosch wrote:
> Either change should be done through a mass change that doesn't cause
> bugmail, so not by a casual contributor without the right bmo
> privileges. Otherwise we're just wasting (a) a lot of their and our
> (collective) time, and (b) don't gain very m
On 09/07/2014 16:27, Daniel Holbert wrote:
On 07/09/2014 08:16 AM, Gijs Kruitbosch wrote:
On 09/07/2014 16:00, Tobias B. Besemer wrote:
My next run would be "Status = Assigned" & "Assigned To =
nob...@mozilla.org" ...
Tobias.
Please don't mass change the target milestone flag on bugs (defini
On 07/09/2014 08:16 AM, Gijs Kruitbosch wrote:
> On 09/07/2014 16:00, Tobias B. Besemer wrote:
>> My next run would be "Status = Assigned" & "Assigned To =
>> nob...@mozilla.org" ...
>>
>> Tobias.
>
> Please don't mass change the target milestone flag on bugs (definitely
> not manually). Same goes
On 09/07/2014 16:00, Tobias B. Besemer wrote:
Am Mittwoch, 9. Juli 2014 03:51:32 UTC+2 schrieb Tobias B. Besemer:
I tried to help and clean up a bit Bugzilla with updating the "Target
Milestone" to a Milestone that get still developed ...
I did this:
https://bugzilla.mozilla.org/buglist.cgi?f
Am Mittwoch, 9. Juli 2014 03:51:32 UTC+2 schrieb Tobias B. Besemer:
> I tried to help and clean up a bit Bugzilla with updating the "Target
> Milestone" to a Milestone that get still developed ...
I did this:
https://bugzilla.mozilla.org/buglist.cgi?f1=OP&f0=OP&classification=Components&emailtype
On 7/9/2014 2:47 AM, Chris Peterson wrote:
Despite its name, the "Target Milestone" field is usually left unset
until *after* the bug is fixed. Then "Target Milestone" is set to the
version of Firefox Nightly that was fixed (e.g. Nightly 33 is
"mozilla33"). Even if a bug fix is uplifted from Nigh
Interesting point. What's the profile of users who write comments on
crash reports? Would they click on a button "add comments"?
On 08/07/14 21:33, Honza Bambas wrote:
>> This would probably eliminate most comments we get on crash reports.
>> Even if a good number of those are not helpful now, a s
On 09.07.2014 01:41, Ehsan Akhgari wrote:
> On 2014-07-08, 6:34 PM, L. David Baron wrote:
>> On Monday 2014-07-07 15:18 -0400, Ehsan Akhgari wrote:
>>> That seems pretty bad. I think we should at least stop supporting
>>> it for Web content. David, what do you think?
>>
>> I'm ok with restricting
23 matches
Mail list logo
