I believe the most elegant and quick (seemingly) solution is to provide the
extension developers a field (in the extension gallery, not in the extension
itself) that will include the platform and the version.
Going farther, you can add a check if the platform and the version (or even
let the
One viewpoint I haven't seen mentioned on this thread is from that of
the extension developer. Suppose they write, from their perspective, a
perfectly good extension that uses binary components. After being
around for a few weeks, they notice they have a 2-star rating and a
lot of angry comments
If I'm running on Windows, I know to ignore the latter. That's a
pretty big difference.
-- Dirk
On Fri, Dec 11, 2009 at 7:39 AM, Avi Drissman a...@chromium.org wrote:
What the difference between:
★ this extension doesn't work at all wh
and
★ As mentioned, this
Right, but the rating average doesn't take that into account.
Avi
On Fri, Dec 11, 2009 at 12:59 PM, Dirk Pranke dpra...@google.com wrote:
If I'm running on Windows, I know to ignore the latter. That's a
pretty big difference.
-- Dirk
On Fri, Dec 11, 2009 at 7:39 AM, Avi Drissman
Andy sent me a CL for review about an extension crashing (
http://crbug.com/29584). Turns out the cause was a failure to load a Windows
.dll on the Mac.
Huh? Then I went to look at the docs (
http://code.google.com/chrome/extensions/npapi.html):
{
name: My extension,
...
*plugins: [
{
http://codereview.chromium.org/492012
So the design is for every platform to try to load all plugins. We don't
even want to have a hint that allows the website to say this is
Windows-only?
How about from the browser perspective? Is failure to load a library a fatal
error? (Sorry, we can't load
Yeah, that's very bad. I knew the NPAPI syntax sucked, but we punted on it
because we didn't like any of the alternatives. (Even if we do have a
manifest syntax for it, the extension package becomes bloated with plugin
binaries for other platforms.) But I didn't realize that it could cause a
Can we at least deny installing the extension in Chromium if it contains
plugins that cannot be used in that operating system for now until a better
design for cross-platform manifest?
- Mohamed Mansour
On Thu, Dec 10, 2009 at 7:15 PM, Matt Perry mpcompl...@chromium.org wrote:
Yeah, that's
The crash is fixed. But the fact that we're now expecting random dll loads
to fail prevents us from giving good UI to users, and not labelling what
platforms it'll work on prevents us from warning in advance.
Imagine a million angry Mac and Linux users filing bugs because their
favorite extension
Can we have the syntax say platform x loads x.dll, platform y loads y.so,
etc?
If a dll required by a platform fails to load, we need to alert the user
that their extension is busted. The prospect of having failure to load
binaries be an expected thing scares me.
Avi
On Thu, Dec 10, 2009 at
On Thu, Dec 10, 2009 at 4:03 PM, Avi Drissman a...@chromium.org wrote:
Andy sent me a CL for review about an extension crashing
(http://crbug.com/29584). Turns out the cause was a failure to load a
Windows .dll on the Mac.
We have had threads on this before. The consensus was that it was
On Thu, Dec 10, 2009 at 4:27 PM, Avi Drissman a...@google.com wrote:
Can we have the syntax say platform x loads x.dll, platform y loads y.so,
etc?
Yes that is the idea.
If a dll required by a platform fails to load, we need to alert the user
that their extension is busted. The prospect of
It is good that we can avoid the crash. We do need to get some kind of
syntax in the manifest.
- a
On Thu, Dec 10, 2009 at 4:18 PM, Avi Drissman a...@google.com wrote:
The crash is fixed. But the fact that we're now expecting random dll loads
to fail prevents us from giving good UI to users,
On Thu, Dec 10, 2009 at 4:03 PM, Avi Drissman a...@chromium.org wrote:
If we had something like:
plugins: {
mac: ...
win: ...
linux: ...
}
FWIW, one reason to avoid this sort of thing is that there is really
no single thing called linux to target. For example, because our
builds of
Is there a timetable? http://crbug.com/14936 has been Mstone-Xed since June.
Avi
On Thu, Dec 10, 2009 at 7:30 PM, Aaron Boodman a...@google.com wrote:
On Thu, Dec 10, 2009 at 4:27 PM, Avi Drissman a...@google.com wrote:
Can we have the syntax say platform x loads x.dll, platform y loads
On Thu, Dec 10, 2009 at 7:36 PM, Evan Martin ev...@google.com wrote:
Distributing binaries on Linux = sadness, as the Flash guys will tell
you.
[...]
In summary, all I offer you is more problems and the plea that we
should really really deter people from doing this kind of thing. I
imagine
On Thu, Dec 10, 2009 at 4:38 PM, Avi Drissman a...@google.com wrote:
On Thu, Dec 10, 2009 at 7:36 PM, Evan Martin ev...@google.com wrote:
Distributing binaries on Linux = sadness, as the Flash guys will tell
you.
[...]
In summary, all I offer you is more problems and the plea that we
On Thu, Dec 10, 2009 at 7:55 PM, Ojan Vafai o...@google.com wrote:
I think we can wait to see what percentage of extensions actually include
binaries before devoting too much time to this. Our expectation is that this
will be a very small percentage, right?
Quick, look at
On Thu, Dec 10, 2009 at 4:03 PM, Avi Drissman a...@chromium.org wrote:
Andy sent me a CL for review about an extension crashing (
http://crbug.com/29584). Turns out the cause was a failure to load a
Windows .dll on the Mac.
Huh? Then I went to look at the docs (
On Thu, Dec 10, 2009 at 8:00 PM, Ojan Vafai o...@chromium.org wrote:
I think we can wait to see what percentage of extensions actually include
binaries before devoting too much time to this. Our expectation is that this
will be a very small percentage, right?
If we give people the
On Thu, Dec 10, 2009 at 5:02 PM, Avi Drissman a...@google.com wrote:
Q: Can't we have the extensions gallery warn that it won't work?
A: Sorry, we can't do that in an automated fashion. The extensions author
should mention it. Too bad they don't.
But we explicitly review patches with binary
On Thu, Dec 10, 2009 at 5:05 PM, Avi Drissman a...@google.com wrote:
On Thu, Dec 10, 2009 at 8:00 PM, Ojan Vafai o...@chromium.org wrote:
I think we can wait to see what percentage of extensions actually include
binaries before devoting too much time to this. Our expectation is that this
We do? I didn't know that. Then we should enforce some kind of labeling.
Avi
On Thu, Dec 10, 2009 at 8:12 PM, Peter Kasting pkast...@google.com wrote:
On Thu, Dec 10, 2009 at 5:02 PM, Avi Drissman a...@google.com wrote:
Q: Can't we have the extensions gallery warn that it won't work?
A:
Or reject extensions that could be written without a NPAPI component.
*ducks*
On Thu, Dec 10, 2009 at 5:12 PM, Peter Kasting pkast...@google.com wrote:
On Thu, Dec 10, 2009 at 5:02 PM, Avi Drissman a...@google.com wrote:
Q: Can't we have the extensions gallery warn that it won't work?
A:
Much of what can't be done on the web platform also can't be done inside the
NaCl sandbox.
On Thu, Dec 10, 2009 at 5:49 PM, John Abd-El-Malek
jabdelma...@google.comwrote:
NaCl is the answer to all these problems...
On Thu, Dec 10, 2009 at 5:15 PM, Jeremy Orlow jor...@google.com wrote:
Or
NaCl is the answer to all these problems...
On Thu, Dec 10, 2009 at 5:15 PM, Jeremy Orlow jor...@google.com wrote:
Or reject extensions that could be written without a NPAPI component.
*ducks*
On Thu, Dec 10, 2009 at 5:12 PM, Peter Kasting pkast...@google.comwrote:
On Thu, Dec 10, 2009 at
The goal is to expose all this through Pepper.
On Thu, Dec 10, 2009 at 5:50 PM, Jeremy Orlow jor...@chromium.org wrote:
Much of what can't be done on the web platform also can't be done inside
the NaCl sandbox.
On Thu, Dec 10, 2009 at 5:49 PM, John Abd-El-Malek jabdelma...@google.com
Yes, extensions that include NPAPI are a very small minority. Last
time I checked there were something like 5. It is a way out for people
who already have binary code that they would like to reuse, or who
need to talk to the platform.
I don't see what the big deal is about a few extensions only
28 matches
Mail list logo
