, we should fix them. :)
Thanks for putting this together!
-mike
On Thu, Jul 9, 2015 at 5:28 PM, Daniel Veditz wrote:
> On Mon, Jul 6, 2015 at 2:47 AM, Mike West wrote:
>
>> I've dropped the opener/openee-disowning behavior from my proposal,
>> and renamed the sandboxing keyword to `allow-popups-to-escape-sandbox` in
>>
>>
On Mon, Jul 6, 2015 at 9:14 PM, Boris Zbarsky wrote:
> On 7/6/15 5:47 AM, Mike West wrote:
>
>> Boris, I think this is consistent with your suggestions in
>>
>> https://groups.google.com/a/chromium.org/d/msg/blink-dev/wXbgxLu63Fo/F6WGG03FafAJ
>> and
>>
>>
On Tue, Jun 23, 2015 at 11:14 AM, Mike West wrote:
> After some conversation with bz (CC'd), I've slightly formalized the
> description of the feature at
> https://wiki.whatwg.org/wiki/Iframe_sandbox_improvments.
>
> This is something that I'd like to ship in Chrome
tps://groups.google.com/a/chromium.org/d/msg/blink-dev/wXbgxLu63Fo/YtsqkySmTWcJ.
Feedback, positive or negative, would be appreciated (either here or
there). :)
-mike
--
Mike West , @mikewest
Google Germany GmbH, Dienerstrasse 12, 80331 München,
Germany, Registergericht und -nummer: Hamburg, HRB 868
ml#sandboxed-plugins-browsing-context-flag),
so this probably isn't an interaction we need to worry about.
-mike
--
Mike West , @mikewest
Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany,
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäfts
On Mon, May 11, 2015 at 6:11 AM, Mike West wrote:
>
> 2. Add a `allow-unsandboxed-auxiliary` keyword to those supported by the
> `sandbox` attribute, which, when present, would allow auxiliary browsing
> contexts created by `window.open` and `target="_blank"` links to c
contexts are
related to a context, but not through nesting:
https://html.spec.whatwg.org/multipage/browsers.html#auxiliary-browsing-contexts.
It's just a definitional thing.
-mike
--
Mike West , @mikewest
Google Germany GmbH, Dienerstrasse 12, 80331 München,
Germany, Registergericht und -nummer: Hamburg,
ng contexts are sandboxed and some
aren't. Especially given the general use case of fourth-, fifth-, and
sixth-party sources, nested somewhere inside the deepest darkest corners of
the iframe displaying the content the user actually sees.
Making it a binary toggle for the frame seems reasonable, gi
king
> the avenue of exploit as well as the phishing risk. It seems there should
> be very few if any use cases for sandboxed content calling
> HTTP-authenticated resources.
>
Yes. That was how I interpreted the suggestion as well; we'd suppress the
dialog by cancelling the requ
On Mon, May 11, 2015 at 11:59 PM, Justin Dolske wrote:
> On Mon, May 11, 2015 at 7:13 AM, Mike West wrote:
>
>> > The worst offender: linking to things that are .htpasswd protected and
>> it
>> > pops up that authentication modal.
>> >
>>
>> I
-popups would be needed (since you shouldn't
> be allowed to open new auxiliary browsing context without it)
>
Correct. Both `allow-popups` and the new flag would need to be specified.
> and maybe is more consistent using 'allow-popups-unsandboxed' ?
>
Or `allow
boxed-auxiliary" keyword on its child iframe, I'm assuming the
> child iframe cannot successfully use "allow-unsandboxed-auxiliary" on a
> child iframe of its own.
>
Yes, this is also how I imagined it working. I should have made that clear
in the proposal, but I thin
;
I wouldn't be terribly averse to dropping support for that inside a
sandbox. Especially a sandbox without `allow-same-origin`.
-mike
--
Mike West , @mikewest
Google Germany GmbH, Dienerstrasse 12, 80331 München,
Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft
ad any origin in a
frame. If the `allow-popups` flag is set, it can open auxiliary windows. If
the `allow-forms` flag is set, it can POST to arbitrary origins.
-mike
--
Mike West , @mikewest
Google Germany GmbH, Dienerstrasse 12, 80331 München,
Germany, Registergericht und -nummer: Hamburg, HRB
`allow-unsandboxed-auxiliary` keyword (it wouldn't change the behavior of
any existing sandboxed frame), and browsers generally throttle the creation
of popups in various ways (Chrome allows only one popup per user gesture,
for instance).
--
Mike West , @mikewest
Google Germany GmbH, Diener
a `allow-unsandboxed-auxiliary` keyword to those supported by the
`sandbox` attribute, which, when present, would allow auxiliary browsing
contexts created by `window.open` and `target="_blank"` links to create
clean browsing contexts, unaffected by the sandbox which spawned them.
WDYT?
ve similar security
> guarantees.
>
I'll reassert that this proposal is simpler for authors (11 character
opt-in) and users (no change) than the scheme you just outlined. It's more
complex for browser vendors, but that's fine and expected, as we're way
down at the bottom
On Thu, Oct 16, 2014 at 12:16 PM, Eduardo' Vela"
wrote:
> On Thu, Oct 16, 2014 at 11:59 AM, Mike West wrote:
>
>> On Thu, Oct 16, 2014 at 10:36 AM, Eduardo' Vela"
>> wrote:
>>
> OK, so it's just being locked down out of a formality, but has
ess time with a lot less resources than deployed CSP across all
> of Google. So yes, it's easier.
>
That surprises me.
Still, I suspect both are significantly more work than adding an attribute
to a form field.
--
Mike West
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162
On Thu, Oct 16, 2014 at 11:43 AM, John Mellor wrote:
> On 16 October 2014 08:52, Mike West wrote:
>
>> * Server stores credentials as `sha512(password + username)`.
>>
>
> It might be better to require PBKDF2/bcrypt/scrypt.
>
Yeah, that certainly makes sense.
-mike
into your site's
template" and not "rewrite your authentication stack from the ground up
using technologies you've never heard of", I think it's something we can
reasonably ask of authors. The central advantage of the writeonly proposal
is that it's a trivial drop-
s tough to keep track of
the origin of an action, especially when that action is the result of an
event handler or some other asynchronous action that no longer has a clear
call stack back to it's originator.
It's unlikely to be implemented. CSP locking down the sources of script is
the
's
job harder, but certainly not impossible. It is not revolutionary in any
sense, but throws up some new roadblocks, and is _trivial_ for a website
author to implement. That last bit is important.
> The reason why I was previously skeptical of proposals of write-only
> fields is pretty much because the threat model is so complicated and
> the solutions are so fragile - but maybe I'm in the wrong on this.
>
I hope you are, as this is a problem I'd like to address.
-mike
us a clear indication that the site doesn't
intend to do wacky manipulation of its credentials on the fly. We can use
this to determine how and when the password manager (or credit card
autofill, or whatever) ought to refuse to expose information to the
renderer.
--
Mike West
Google+: https:
e"?
>
The strawman suggests setting a flag on the element, and doesn't suggest a
way of unsetting that flag. This is conceptually similar to iframe@sandbox's
effect on the document loaded into the frame.
--
Mike West
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162
imum require a CSP with
> form-action specified, and otherwise warn or better yet, break fields
> flagged as writeonly.
>
Sure. Doing one or both is probably pretty reasonable. :)
-mike
ts in
order to do the right thing with regard to ServiceWorkers, but since we
already track opaqueness for responses, I hope that's not an overly
burdensome taint to track.
-mike
--
Mike West
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91
Google Germany GmbH, Dienerst
strawman hints at that, but I haven't done the
work to find all the places to monkey-patch.
-mike
--
Mike West
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91
Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
s at Mozilla (the
former in relation to Fetch, the latter in relation to a proposed
Credential Management API). Neither jumped on it as the best thing ever,
but they were both more than marginally supportive.
Thanks!
--
Mike West
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 25
Mathias, Anne
I really believe that the notification api is a related topic but can exist as
a separate api used in page icon. I think it’s a good idea not to bind them
together.
Mike Tomshinsky
tomshin...@yandex-team.ru
On 26 авг. 2014 г., at 10:50, Anne van Kesteren wrote:
> On Tue,
says no to any API;)
Mike Tomshinsky
tomshin...@yandex-team.ru
On 26 авг. 2014 г., at 10:42, Tab Atkins Jr. wrote:
> On Tue, Aug 26, 2014 at 4:21 PM, Anne van Kesteren wrote:
>> On Mon, Aug 25, 2014 at 8:59 PM, Mike wrote:
>>> 2) There is already a couple of standards
standard or it’s
already too tight among those semi-standards?
Mike Tomshinsky
Yandex.Browser
tomshin...@yandex-team.ru
that weird.
That said, an alternative might be to add a mechanism of associating
autocompletion metadata with the field in order to give the UA enough
context to fill it in. For example, if a password is being requested for a
known username, that username could be added as an new
"autocomplete
On 2/18/14, 17:55, Mike Taylor wrote:
On 2/18/14, 17:17, Ian Hickson wrote:
On Tue, 18 Feb 2014, Jonathan Watt wrote:
The question is, should I change Mozilla's implementation to stop
displaying the internal value using grouping separators, or is it wrong
to use for year input. I'm
like to solicit others' thoughts on this matter.
My recommendation would be to just use comma separation for numbers
greater than .
Perhaps unrelated, but that would solve the
type=number-for-tcp-ports-looks-kinda-weird problem:
https://cloudup.com/cKEisWEkvjv
--
Mike Taylor
Web Compat, Mozilla
Ping. Is this a terrible idea? :)
--
Mike West , Developer Advocate
Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91
On Sat, Feb 2, 2013 at 7:11 PM, Mike West wrote:
> It's currently possible to
;d propose adjusting the spec to include a sandboxed downloads flag,
which, when present, would block all downloads from inside the frame (or,
perhaps only require user confirmation?). This restriction could be lifted
via an 'allow-downloads' keyword, if present in the sandbox attribute
in the
sandboxed case.
What should the expected behavior in this case be? Given the way that
MessageEvent sets the origin of a message from a sandboxed frame to
the string "null", that seems like a reasonable option here as well.
WDYT?
[1]: https://bugs.webkit.org/show_bug.c
r body
-- -- -- -- --
beforeunld domloaddomloadbeforeunld beforeunld
domloadunload beforeunldunload
unloadunload
Interesting stuff indeed :-)
Best regards
Mike
Thanks Ian,
Ian Hickson wrote on 14 december 2012 19:22:
> On Fri, 14 Dec 2012, Mike Wilson wrote:
> >
> > What events are supposed to be fired when the browsing context
> > gets navigated away before the current page has finished
> > loading, ie before the load even
Since a URL query string is not a strict map with only one value for a
key, would the get/set operations allow for an array as well as an
atomic value?
On Fri, Oct 12, 2012 at 3:02 PM, Glenn Maynard wrote:
>
> The object paradigm is more natural for the common case:
>
> query.values["key"] = val
#L429-436
--
Mike Taylor
Opera Software
ne column, full size. So one image is created at
the three most likely sizes (1/1, 1/2, 1/3) and then srcset is used to make
sure the
--
Mike Gossmann
Mathew Marquis wrote:
>On May 22, 2012, at 5:43 AM, Anne van Kesteren wrote:
>
>> On Tue, May 22, 2012 at 10:21 AM, Markus
ess the variable can
strip the sizes out on it's own.
--
Mike Gossmann
en you
can just have sizes="100x100 200x200"
This gives the designer/developer full control over the shape and size of the
image element (through CSS), while still allowing the browser to make decisions
based on bandwidth and whatnot.
--
Mike Gossmann | m...@c572.ca | http://gossmati.ca
On Wed, 16 May 2012 08:40:46 -0500, Matthew Wilcox
wrote:
What's the actual WHATWG proscribed format for conducting conversations
in email
format?
See http://wiki.whatwg.org/wiki/FAQ#Should_I_top-post_or_reply_inline.3F
--
Mike Taylor
Opera Software
m/1761168
I would love to believe that all developers would use this proposal "for
good", as it were. Experience leads me to believe it will be just another
technique sniffed and served to the regular suspects.
--
Mike Taylor
Opera Software
for this:
http://dev.w3.org/2006/webapi/clipops/clipops.html. A search for
"clipboard data API" in the archives might bring up some interesting
discussion as well.
Cheers,
--
Mike Taylor
Opera Software
2011/12/14 Anne van Kesteren :
> On Wed, 14 Dec 2011 18:18:30 +0100, Mike Samuel
> wrote:
>>
>> This is a potential source of confusion for naive HTML entity decoders
>> fall-back to case-insensitive matching when there is no mapping for a
>> given entity name.
>
The table in section 12.5 (
http://www.whatwg.org/specs/web-apps/current-work/multipage/named-character-references.html
) says
> GT;U+0003E>
> Gt;U+0226B≫
> gt;U+0003E>
> GT U+0003E>
> gt U+0003E>
which I believe means that ">", ">",">",
On Oct 31, 2011, at 3:53 AM, Mikko Rantalainen wrote:
> 2011-10-27 14:29 EEST: Henri Sivonen:
>> On Thu, Oct 20, 2011 at 9:57 PM, Martin Boßlet
>> wrote:
>>> Are there plans in this direction? Would functionality like this have a
>>> chance to be considered for the standard?
>>
>> The chances ar
On Fri, Oct 28, 2011 at 11:52 AM, Philip Jägenstedt wrote:
> On Fri, 28 Oct 2011 12:58:01 +0200, David Håsäther
> wrote:
>
> It would be more useful if the DOMTokenList methods (contains, add,
>> remove, toggle) would take a space separated list of tokens. This is
>> the behavior most DOM librar
On Jul 26, 2011, at 2:44 PM, Ian Hickson wrote:
> On Fri, 29 Apr 2011, Simon Heckmann wrote:
>>
>> I have read a lot in the last month about the future of html and web
>> applications and I am very impressed by the progress this makes.
>> However, I have come across some thing that annoys me: P
Mike Wilson wrote:
John J. Barton wrote:
Step 14 is unclear or incomplete however:
" If the src
<http://www.whatwg.org/specs/web-apps/current-work/#attr-script-src>
attribute's value is the empty string or if it could not be resolved,..."
Does this mean the error handler
case of 4XX, 5XX, and
syntax errors?
If you follow the algorithm a bit further down you have this in step 15.2:
If the load resulted in an error (for example a DNS error, or an HTTP 404
error)
Executing the script block must just consist of firing a simple event named
error at the element.
Best regards
Mike
Hi John,
This event is actually already speced, see #14 "fire a simple event
named error at the element" in:
http://www.whatwg.org/specs/web-apps/current-work/#prepare-a-script
(and the onerror attribute is valid for all elements)
Best regards
Mike Wilson
John J. Barton wrote:
be a
useful distinction.
I suspect that it will be useful to lightly separate the "math" conversation
from the "authority" conversation - they are both interesting but they probably
involve different people and different concerns.
-Mike
On May 23, 2011, at 9:05 PM, Jonas
On 3/1/11 1:54 PM, usuario wrote:
According to the spec:
The body element represents the body of a document (as opposed to the
document’s metadata).
I think definition is a bit ambiguous.
Why not propose a better definition then?
o implement
window.forms. and other dynamically-reflected properties?
Mike
s in other browsers as well.
So can we then say that
http://www.whatwg.org/specs/web-apps/current-work/#navigating-across-documen
ts
probably needs updating?
Is the fix as simple as moving step 9 to the position between
current step 11 and 12? (directly after beforeunload)
Best regards
Mike
load events
and all.
Did I miss something?
Best regards
Mike Wilson
to the document.
Best regards
Mike Wilson
Mike Wilson wrote on December 26, 2010:
> http://www.whatwg.org/specs/web-apps/current-work/#navigating-
> across-documents
> (as of December 26, 2010)
> | When a browsing context is navigated to a new resource, the
> | user agent must run th
Firefox, Safari or Chrome :-P
Best regards
Mike Wilson
ucture pictures at 27:57 and forward)
Best regards
Mike Wilson
.)
Best regards
Mike Wilson
2010/9/20 Julian Reschke
> On 20.09.2010 17:26, Mike Belshe wrote:
>
>> ...
>>
>> LINK, in general, allows a server to indicate to a client that it will
>> need a particular resource earlier than the client otherwise would have
>> discovered it. Today,
der attributes, you could
instead aim your question at HTTP - why does HTTP bother with
if-modified-since?But the answer is moot - that decision was made long
ago.
Given that the web *does* use these basic cache control mechanisms, why
*wouldn't* you want the LINK header to be capable
ese are optional attributes, and any browser not recognizing these
> attributes will just perform some cache-validations, just as they do today.
> These attributes should speed up browsers that support them without
> changing behaviour of other browsers that don't.
>
> - Gavin
>
> (thank you to Mike Benna @ Strangeloop for suggesting these attributes to
> us!)
>
es this mean that you're expecting that the ignored calls didn't
matter? Surely having parts of the drawing be missing will often be
noticed by users as well!
Mike
may be less of a problem if Robert's proposal can
> just be taken wholesale, though).
RE: Fullscreen - I would be happy if the warning text was removed:
User agents should not provide a public API to cause videos to be shown
full-screen.
Mike Wilcox
http://clubajax.org
m...@mikewilcox.net
hing that annoys us. Greater than 100% volume has a very solid
use case. Setting a property to 1.5 is much easier than re-encoding a video.
Mike Wilcox
http://clubajax.org
m...@mikewilcox.net
On Aug 15, 2010, at 7:53 PM, Robert O'Callahan wrote:
>
> Tables?
TDs are inline and TRs act as line breaks.
> Is there any documentation for how the serialization works?
I'm just running the tests as you guys request them. I'm not sure if or how
well this feature is spec'd out.
Mike
On Aug 15, 2010, at 7:29 PM, Robert O'Callahan wrote:
> What about lists? Alt text in ?
It handles lists and the line breaks, but it doesn't indent.
Image attributes are ignored.
Mike
On Aug 15, 2010, at 6:26 PM, Jonas Sicking wrote:
> On Sun, Aug 15, 2010 at 11:17 AM, Mike Wilcox wrote:
>> innerText is one of those things IE got right, just like innerHTML. Let's
>> please consider making that a standard instead of removing it. Also, please
>>
the node is a block (or
list-item, etc), because you then need to know if it is a block compared to the
next and previous nodes; else a span in a p will get line breaks.
Mike Wilcox
http://clubajax.org
m...@mikewilcox.net
On Aug 15, 2010, at 7:41 AM, Michael A. Puls II wrote:
> On Sat, 1
ked, but I read that Opera's innerText implementation is
essentially an alias of textContent.
Mike Wilcox
http://clubajax.org
m...@mikewilcox.net
On Aug 14, 2010, at 5:39 PM, Adam Barth wrote:
> == Use Case ==
>
> It's common that a web page has a string of untrusted cha
I'm perplexed at the resistance. We've tried telling our clients not to use
IE6, "IE8 is much faster". But inevitably, we have to make it work.
Mike Wilcox
http://clubajax.org
m...@mikewilcox.net
On Aug 11, 2010, at 8:29 PM, Boris Zbarsky wrote:
> On 8/11/10 9:17
ear win. But
without recording both metrics, we just don't really know how to evaluate if
a feature is good or bad.
Sorry to send you through more work - I am not trying to nix your feature
:-( I think it is great you are taking the time to study all of this.
Mike
>
> -Justin
&
This seems like the ideal situation to use a placeholder attribute:
Foo
Bar
None
Mike Wilcox
http://clubajax.org
m...@mikewilcox.net
paint. So - is it possible to measure both times? I'm betting
time-to-paint goes through the roof with resource bundles:-)
If you provide the content, I'll try to run some tests. It will take a few
days.
Mike
On Mon, Aug 9, 2010 at 9:52 AM, Justin Lebar wrote:
> On Mon, Aug 9, 2010 at
ke up
100%. I have to assume this is what the UA would be doing in the background
anyway in order to keep the proper x/y coordinates.
Mike Wilcox
y be over thinking it.
allowFullscreen="userIntiated,mouseOnly" is probably all that is needed in this
case (and perhaps most cases).
Of course, nothing is 100% secure, and since this is the list that said DRM is
impossible, I'm really advocating that we don't try for 100% sa
isions between future Array.prototype and
HTMLCollection fields.
Mike
On Thu, Jul 22, 2010 at 5:32 PM, Luke Hutchison wrote:
> On Thu, Jul 22, 2010 at 5:03 PM, Mike Shaver wrote:
>> What is the proposed change to which specification, exactly? URL-bar
>> behaviour, especially input permission, seem out of scope for the
>> specs that the
L scheme is used) be
compliant?
What should the URL bar say when the user clicks a javascript: link
which produces content? five!
Mike
On Wed, Jul 21, 2010 at 10:24 AM, Chris Double
wrote:
> On Thu, Jul 22, 2010 at 2:15 AM, Mike Shaver wrote:
>> ...I would probably suggest that the
>> developers of said browser implement basic Ogg support (enough to say
>> "this is Ogg, so we don't support it
s users, I would probably suggest that the
developers of said browser implement basic Ogg support (enough to say
"this is Ogg, so we don't support it"), and go back to solving more
pressing problems!
Mike
On Wed, Jul 21, 2010 at 10:04 AM, Philip Jägenstedt wrote:
> Right, sniffing is currently only done in the context of , at least
> in Opera. The problem could be fixed by adding more sniffing, certainly.
A warning that you're about to open a 5MB "text" document might be
humane anyway. :-)
Mike
sniff?" question is about. Do you mean
sniffing for selection? Otherwise, it seems like you have all
the data you need as a matter of course, and it doesn't really matter
how far into the bitstream you go before you decide what
codec/options/etc. is in play.
Mike
On Wed, Jul 21, 2010 at 9:51 AM, Philip Jägenstedt wrote:
> On Wed, 21 Jul 2010 15:15:18 +0200, Mike Shaver
> wrote:
>> Could you be more specific about the incorrect information? My
>> understanding, from this thread and elsewhere, is that video formats
>> are
Do browsers use
HEAD to check for video compatibility today?
Mike
On Wed, Jul 21, 2010 at 9:43 AM, Nils Dagsson Moskopp
wrote:
> Mike Shaver schrieb am Wed, 21 Jul 2010
> 09:15:18 -0400:
>> and furthermore that the appropriate MIME type
>> for ogg-with-VP8 vs ogg-with-theora isn't clear (or possibly even
>> extant).
>
> A
ts
are reliably sniffable, and furthermore that the appropriate MIME type
for ogg-with-VP8 vs ogg-with-theora isn't clear (or possibly even
extant). It seems like reliance on MIME type will result in more of
the guessing-and-stupid-switches than sniffing.
Mike
" for this option (I don't believe Flash supports
this).
I don't think the CSS3 box-sizing:border-box helps.
Does voting count? +1!
Mike Wilcox
http://clubajax.org
m...@mikewilcox.net
On Jul 19, 2010, at 10:08 AM, Nick wrote:
> Canvas would benefit from a way to set stroke
are the gold standard of a high performance website. While
this may or may not explain the things that don't validate, what it does say is
that nothing coming from google.com is accidental.
Mike
On Jul 12, 2010, at 7:58 AM, Julian Reschke wrote:
> On 12.07.2010 14:44, Mike Wilcox wrote:
>> On Jul 12, 2010, at 2:30 AM, Julian Reschke wrote:
>>> Google:
>>> <http://validator.w3.org/check?uri=http%3A%2F%2Fwww.google.com&charset=%28detect+automatically%2
ed, incorrect HTML
in ways that still render in a browser in order to make it more difficult for
screen scrapers. They also "break it" in a different way every week.
Mike Wilcox
http://clubajax.org
m...@mikewilcox.net
It's the iPhone and especially the iPad which has really pushed the adoption of
HTML5 video. And afaik, you can't install WebM on them. To me (and my company)
that's where the issue lies.
Mike Wilcox
http://clubajax.org
m...@mikewilcox.net
On Jul 5, 2010, at 3:46 PM, Sh
RC).
There were two revision periods, I think, one as you describe that got
us off JAR files (thank the stars), and then another later on, which
is the one to which I am referring. I could be grotesquely
misremembering, though, so I'll retract my comment rather than try to
find records of the conversations!
Mike
1 - 100 of 405 matches
Mail list logo
