On 7/7/2014 5:25 PM, Jonathan Griffin wrote:
Filed https://bugzilla.mozilla.org/show_bug.cgi?id=1035464 for those
that would like to follow along.
Perhaps bug 890116 is a better measure of tracking.
--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist
_
Filed https://bugzilla.mozilla.org/show_bug.cgi?id=1035464 for those
that would like to follow along.
Jonathan
On 7/7/2014 3:22 PM, Jonathan Griffin wrote:
So it sounds like it would be valuable to add try syntax to trigger
this, as well as produce periodic reports. Most of the work needed
So it sounds like it would be valuable to add try syntax to trigger
this, as well as produce periodic reports. Most of the work needed is
the same.
I'll file a bug to track this; I don't have an ETA for starting work on
it, but we want to get to it before things bitrot.
Jonathan
On 7/7/20
On 7/7/2014 3:21 PM, Ehsan Akhgari wrote:
> We should keep in mind that sometimes due to startup crashes, we don't
> get to run any of the code in Firefox, so we can't gate the crash
> report submission on that code at least in the case of startup crashes.
>
I believe this was the primary reasoning
On 7/7/2014 1:11 PM, Jonathan Griffin wrote:
I guess a related question is, if we could run this periodically on
TBPL, what would be the right frequency?
Several years ago, I did a project where I ran code-coverage on roughly
every nightly build of Thunderbird [1] (and I still have those
resu
On 07/07/14 21:21, Ehsan Akhgari wrote:
> We should keep in mind that sometimes due to startup crashes, we don't
> get to run any of the code in Firefox, so we can't gate the crash report
> submission on that code at least in the case of startup crashes.
>
> Cheers,
> Ehsan
Yes, we clearly need t
We should keep in mind that sometimes due to startup crashes, we don't
get to run any of the code in Firefox, so we can't gate the crash report
submission on that code at least in the case of startup crashes.
Cheers,
Ehsan
On 2014-07-05, 8:21 AM, David Rajchenbach-Teller wrote:
I haven't expe
That seems pretty bad. I think we should at least stop supporting it
for Web content. David, what do you think?
Cheers,
Ehsan
On 2014-07-07, 4:56 AM, Frederik Braun wrote:
Summary:
Attackers can extract secret URL components (e.g. session IDs, oauth
tokens) using @-moz-document. Using the r
This looks awesome, Joshua! Thanks for doing this. CCing Sylvestre who
has also started to look into this...
Cheers,
Ehsan
On 2014-07-07, 1:02 AM, Joshua Cranmer 🐧 wrote:
I don't know how many people follow code-coverage updates in general,
but I've produced relatively up-to-date code cover
I'm sorry, I don't seem to understand what you're saying. You seem to be
saying: "JS files that implement XPCOM interfaces [which you can't test]
without exposing them via an interface". Which prompts me to ask:
Does the code, without taking testing into account, need to implement an
interface
What about wrappedJSObject? If the test is geared towards internal
details of the implementation anyway, it should be possible to do
something like this:
xpcom component:
function MyXPCOMComponent() {
this.wrappedJSObject = this;
}
MyXPCOMComponent.prototype = {
_internalMethod: function(a
On Mon, Jul 7, 2014 at 11:11 AM, Jonathan Griffin
wrote:
> I guess a related question is, if we could run this periodically on TBPL,
> what would be the right frequency?
>
> We could potentially create a job in buidlbot that would handle the
> downloading/post-processing, which might be a bit fas
I guess a related question is, if we could run this periodically on
TBPL, what would be the right frequency?
We could potentially create a job in buidlbot that would handle the
downloading/post-processing, which might be a bit faster than doing it
on an external system.
Jonathan
On 7/7/2014
On Sun, Jul 6, 2014 at 10:02 PM, Joshua Cranmer 🐧
wrote:
> Effectively, only xpcshell tests, and the M, M-e10s, and R groups are
> represented in the output data. M-e10s is slightly borked: only M-e10s(1)
> [I think] is shown, because, well, treeherder didn't distinguish between
> the five of the
On 7/7/14, 10:53 AM, Josh Matthews wrote:
Garvan is referring to JS files that implement XPCOM interfaces. It's
impossible to test internal details of the components without exposing
them via an interface, which can end up convoluting the code in some cases.
Really? I thought you could Cu.impor
On 7/7/2014 1:53 PM, Josh Matthews wrote:
Garvan is referring to JS files that implement XPCOM interfaces. It's
impossible to test internal details of the components without exposing
them via an interface, which can end up convoluting the code in some
cases.
I expect you can import them usin
On 7/4/14, 7:46 AM, David Rajchenbach-Teller wrote:
Well, we basically have the Windows version implemented already. We
could possibly use Watchman for other platforms. How do others feel
about introducing a dependency towards Watchman?
The inotify limitation on watchers is indeed annoying in th
Garvan is referring to JS files that implement XPCOM interfaces. It's
impossible to test internal details of the components without exposing
them via an interface, which can end up convoluting the code in some cases.
Cheers,
Josh
On 07/07/2014 12:32 PM, Gijs Kruitbosch wrote:
On 07/07/2014 17
On 7/7/2014 11:39 AM, Jonathan Griffin wrote:
Hey Joshua,
That's awesome!
How long does the try run take that generated this data? We should
consider scheduling a periodic job to collect this data and track it
over time.
Well, it depends on how overloaded try is at the moment. ^_^
The bui
On Tuesday, July 1, 2014 12:58:45 PM UTC-7, Koji Ishii wrote:
> Summary:
>
> Two recent HTML changes improve ruby support:
>
> 1) Addition of the rb and rtc elements (but not rbc); and
>
> 2) Matching update to the tag omission rules to make ruby authoring easier.
>
> By implementing these chan
Hey Joshua,
That's awesome!
How long does the try run take that generated this data? We should
consider scheduling a periodic job to collect this data and track it
over time.
Jonathan
On 7/6/2014 10:02 PM, Joshua Cranmer 🐧 wrote:
I don't know how many people follow code-coverage updates in
On 07/07/2014 17:25, gkee...@mozilla.com wrote:
We have no unit test framework for internal JS, does anyone have any
interesting ideas on how to accomplish this with our existing testing
frameworks?
Should I just leave unit testing functions in the JS file, so they can be run
manually during
On 07/07/14 09:25, gkee...@mozilla.com wrote:
We have no unit test framework for internal JS, does anyone have any
> interesting ideas on how to accomplish this with our existing testing
> frameworks?
I've successfully used mochitest with specialpowers to access the
internal interfaces. xpcsh
We have no unit test framework for internal JS, does anyone have any
interesting ideas on how to accomplish this with our existing testing
frameworks?
Should I just leave unit testing functions in the JS file, so they can be run
manually during future development?
__
On 2014-07-04, 7:38 AM, David Rajchenbach-Teller wrote:
Hi,
We are considering redesigning slightly how windows are reopened by
Session Restore, to ensure that most recently used windows are loaded
first. I believe that, in many cases, this would enable users to start
browsing faster.
Seems to me there are advantages to the "more complicated" version anyway.
Whilst it is reasonable to load the contents of the window they are likely to
use first, I'm not sure it follows that you can avoid displaying the other
windows until the first is finished loading. I imagine users could b
(Cc-ing Philipp Sackl, for UX feedback.)
At the moment, the simplified algorithm is the following:
1. Read sessionstore.js;
2. Open first window;
3. Synchronously, for each window in sessionstore.js, in the order in
which the windows have been opened initially, trigger window opening;
(Whenever a
Summary:
Attackers can extract secret URL components (e.g. session IDs, oauth
tokens) using @-moz-document. Using the regexp support and assuming a
CSS injection (no XSS needed!), the attacker can probe the current URL
with some regular expressions and send the URL parameters to a third party.
A
28 matches
Mail list logo
