[chromium-dev] Re: [extensions] RFC: NPAPI manifest change
Why not just let the extension developer do different versions him/herself.
When I download an extension, I don't want to download libraries/plugins
from 10 different architectures. If my operating system is Windows, I would
want to download just the .dll file. The extension developer could release
different versions:
hello_world_win32.crx
hello_world_linux32.crx
Choose whatever filename they please. Maybe include what John stated, a
manifest to tell it what the extension supportedPlatform is, so we would
know at install time that the extension is no supported.
- Mohamed Mansour
On Thu, Sep 10, 2009 at 2:36 PM, jat j...@google.com wrote:
I am building a GWT plugin for Chrome, and I think the manifest should
definitely include some indication of which platform a particular
binary is intended for. Trying to load them all and letting them fail
seems dangerous, as the differences between some platforms may not be
sufficient to prevent the library from loading (say two ELF-based x86
Unix distros).
I think Chrome should come up with a set of platform identifiers that
correspond to what are different builds, and the plugins should be
able to be associated with a particular platform. For backwards
compatibility, we could try and load any plugin without a platform tag
and hope it will fail to load if it isn't compatible, but that should
be deprecated. I think the proposal at the beginning of this thread
is fine, or you could simply add a new tag on the plugins entry, like
this:
...
plugins: [
{ path: WINNT_x86-msvc/foo.dll, public: true, platform:
WINNT_x86-msvc },
{ path: Linux_x86_64-gcc3/libfoo.so, public: true,
platform: Linux_x86-gcc3 },
{ path: Linux_x86_g4-gcc3/libfoo.so, public: true,
platform: Linux_x86_64-gcc3 }
],
...
(path could still be anyway the developer wanted to organize the
libraries). Using a fixed naming convention would work, but it seems
awkward and doesn't save much over just specifying the platform
explicitly.
Also, we need a way to know at install time that the extension is not
supported on the current platform. Since conceivably the extension
might have an optional plugin and still operate without it on some
platforms, I think that means adding a new manifest entry like
supportedPlatforms: [ platforms ], and when you try and install the
CRX it will tell you the extension is not supported on your platform
if that tag is present but does not contain the current platform.
--
John A. Tamplin
Software Engineer (GWT), Google
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: Chromium core principles and multiplatform development?
On Thu, Sep 10, 2009 at 2:05 PM, Jacob Mandelson ja...@mandelson.org wrote: It was more surprised that I was expected to have built chrome at home under multiple platforms. I wouldn't say that we expect people to build chrome at home under multiple platforms. We expect patches not to break any platform--how you do that if you're touching shared code is up to you. Committers have access to try bots specifically so that they can test compilation on platforms they don't have handy, or try patches on behalf of people who don't have commit access yet. There are also plenty of people who can help review patches with an eye towards catching potential platform problems before they land in the tree. I think most coders out there don't have set ups that let them build on all of the three. Requiring that substantially restricts your contributor pool. We don't put any requirements on what setups contributors use. We only put requirements on the effects on the tree. You could submit patches without building them at all, as long as they didn't break anything :-). It's not an unreasonable policy, but it is an atypical one, so I think it should be spelled out in the contributing pages. Yes, we can certainly spell things out better, It's not that in other cross-platform projects Mac or Linux developers don't have to worry about Windows, it's that they aren't expected to have Visual Studio and people that do have it will cooperate with them on problems. Plus there's all the Windows developers that don't happen to have Macintoshes with XCode around... We have many people on all platforms who are happy to cooperate with anyone on problems. --Amanda --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Enabling --disable-hang-monitor for new windows when Chrome is already running
On Thu, Sep 10, 2009 at 5:40 PM, Mike Morearty m...@morearty.com wrote: Then let's say the Flash app hits the line where the breakpoint is. The Flash player notifies Flash Builder of the breakpoint, and then blocks, waiting on a socket until Flash Builder tells it what to do next (e.g. resume, single-step, etc.). The problem is that 30 seconds later, Chrome detects this as a hang (which it is, but it's a deliberate one), and puts up the usual message: The following plug-in is unresponsive: Shockwave Flash Would you like to stop it? Even if I say No, the message keeps reappearing every 30 seconds or so. I'd like to disable the message during debugging. It's easy to launch chrome with --disable-hang-monitor, and that does work, but only if Chrome wasn't already running before I began my debugging session. If Chrome *was* already running, then that flag has no effect. (I suspect probably the new instance of chrome.exe just passed control over to the existing instance, or something like that, and did not tell Chrome to use this flag.) I realize this is somewhat tricky to do. Ideally, that flag would apply to just the one tab or window that I tried to open, but not to all the other already-existing windows. I have not yet looked at the Chrome/Chromium source code, but I wouldn't be surprised if this is currently implemented as a global setting. Is this feasible? Is there some other way to do what I want? Should I log an enhancement request? I have the same problem in the GWT Development Mode plugin. You could set a breakpoint in your Java code in Eclipse, and as far as the browser sees the NPAPI plugin is just hanging until the server lets it continue. It seems like this might be a feature that a number of plugins would like to control, yet you want to make sure it isn't abused by malicious plugins. What about an API call to disable/re-enable it, and control access to that API with permissions in the manifest? -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Enabling --disable-hang-monitor for new windows when Chrome is already running
I think that is a reasonable feature request. It would be nice however if there were some way to know when to restore the old behavior. Unfortunately, Chrome won't know when you are done. -Darin On Fri, Sep 11, 2009 at 2:10 PM, Mike Morearty m...@morearty.com wrote: We just discussed that, and decided against using it, because it could be potentially confusing. Most users would be unaware that we were launching in a separate profile, and even someone who did know that we were doing this would probably find it inconvenient. For example, if he does open another tab in the Chrome instance that we launched, and then browse for a bit, he would now have two separate browser histories -- his main one and the one in our separate user profile. Could get to be a nuisance. For now, I think we're going to go ahead and launch with --disable-hang-monitor, and we may also write a tech note for our users explaining the issue, and suggesting that if they want to, they can add --disable-hang-monitor to the shortcut they use to launch Chrome. I might also log an enhancement request that if my new instance of Chrome passes control to an existing instance, it also pass the value of the --disable-hang-monitor flag, and that the existing instance respects that flag for just that one tab. Thanks! - Mike On Fri, Sep 11, 2009 at 11:49 AM, Adam Barth aba...@chromium.org wrote: You can try using the --user-data-dir flag to point the test instance of Chrome at a dedicated testing profile. That will mean the --disable-hang-monitor instance will actually stay around. Adam On Thu, Sep 10, 2009 at 2:40 PM, Mike Morearty m...@morearty.com wrote: Hi, I'm a developer at Adobe, on the Flash Builder (formerly Flex Builder) team. I'm trying to figure out how to allow --disable-hang-monitor to work even if Chrome is already running. Flash Builder, for those who aren't familiar with it, is a full IDE for creating Flash (and AIR) apps; one of its features is a debugger. So let's say you create a new project, set a breakpoint, and then click Debug. We launch your browser pointing at the Flash app; the Flash player that is inside the browser connects back to Flash Builder. Then let's say the Flash app hits the line where the breakpoint is. The Flash player notifies Flash Builder of the breakpoint, and then blocks, waiting on a socket until Flash Builder tells it what to do next (e.g. resume, single-step, etc.). The problem is that 30 seconds later, Chrome detects this as a hang (which it is, but it's a deliberate one), and puts up the usual message: The following plug-in is unresponsive: Shockwave Flash Would you like to stop it? Even if I say No, the message keeps reappearing every 30 seconds or so. I'd like to disable the message during debugging. It's easy to launch chrome with --disable-hang-monitor, and that does work, but only if Chrome wasn't already running before I began my debugging session. If Chrome *was* already running, then that flag has no effect. (I suspect probably the new instance of chrome.exe just passed control over to the existing instance, or something like that, and did not tell Chrome to use this flag.) I realize this is somewhat tricky to do. Ideally, that flag would apply to just the one tab or window that I tried to open, but not to all the other already-existing windows. I have not yet looked at the Chrome/Chromium source code, but I wouldn't be surprised if this is currently implemented as a global setting. Is this feasible? Is there some other way to do what I want? Should I log an enhancement request? Thanks, - Mike Morearty Sr. Computer Scienstist Adobe Systems Inc. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: last known good git commit?
To simplify Matt's message: $ git svn find-rev r$(curl -s http://chromium-status.appspot.com/lkgr) 8672ced71672761c86c4f5b59d8b49765f35a525 On Fri, Sep 11, 2009 at 1:40 PM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: I think it would be simpler to modify git-cl to know which git commit corresponds to given svn revision. On Fri, Sep 11, 2009 at 13:38, Yaar Schnitman y...@chromium.org wrote: Its easy to tell what is the last known good SVN revision for chrome: http://chromium-status.appspot.com/lkgr But what I need is the corresponding last known good GIT commit. Is there a fast way to get it? (I'm currently greping for the SVN lkgr in the git log) --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Enabling --disable-hang-monitor for new windows when Chrome is already running
Also, the inspector already disables the hang monitor dynamically when it stops at a breakpoint since the renderer is stopped at that point, so this may just be a case of exposing this on-off switch via some API. Erik On Fri, Sep 11, 2009 at 2:26 PM, Evan Martin e...@chromium.org wrote: I guess there's a precedent in the inspector where you can enable various development-related bits (like enable resource tracking). Maybe there's a reasonable place to hook in UI for that there. On Fri, Sep 11, 2009 at 2:24 PM, Darin Fisher da...@chromium.org wrote: I think that is a reasonable feature request. It would be nice however if there were some way to know when to restore the old behavior. Unfortunately, Chrome won't know when you are done. -Darin On Fri, Sep 11, 2009 at 2:10 PM, Mike Morearty m...@morearty.com wrote: We just discussed that, and decided against using it, because it could be potentially confusing. Most users would be unaware that we were launching in a separate profile, and even someone who did know that we were doing this would probably find it inconvenient. For example, if he does open another tab in the Chrome instance that we launched, and then browse for a bit, he would now have two separate browser histories -- his main one and the one in our separate user profile. Could get to be a nuisance. For now, I think we're going to go ahead and launch with --disable-hang-monitor, and we may also write a tech note for our users explaining the issue, and suggesting that if they want to, they can add --disable-hang-monitor to the shortcut they use to launch Chrome. I might also log an enhancement request that if my new instance of Chrome passes control to an existing instance, it also pass the value of the --disable-hang-monitor flag, and that the existing instance respects that flag for just that one tab. Thanks! - Mike On Fri, Sep 11, 2009 at 11:49 AM, Adam Barth aba...@chromium.org wrote: You can try using the --user-data-dir flag to point the test instance of Chrome at a dedicated testing profile. That will mean the --disable-hang-monitor instance will actually stay around. Adam On Thu, Sep 10, 2009 at 2:40 PM, Mike Morearty m...@morearty.com wrote: Hi, I'm a developer at Adobe, on the Flash Builder (formerly Flex Builder) team. I'm trying to figure out how to allow --disable-hang-monitor to work even if Chrome is already running. Flash Builder, for those who aren't familiar with it, is a full IDE for creating Flash (and AIR) apps; one of its features is a debugger. So let's say you create a new project, set a breakpoint, and then click Debug. We launch your browser pointing at the Flash app; the Flash player that is inside the browser connects back to Flash Builder. Then let's say the Flash app hits the line where the breakpoint is. The Flash player notifies Flash Builder of the breakpoint, and then blocks, waiting on a socket until Flash Builder tells it what to do next (e.g. resume, single-step, etc.). The problem is that 30 seconds later, Chrome detects this as a hang (which it is, but it's a deliberate one), and puts up the usual message: The following plug-in is unresponsive: Shockwave Flash Would you like to stop it? Even if I say No, the message keeps reappearing every 30 seconds or so. I'd like to disable the message during debugging. It's easy to launch chrome with --disable-hang-monitor, and that does work, but only if Chrome wasn't already running before I began my debugging session. If Chrome *was* already running, then that flag has no effect. (I suspect probably the new instance of chrome.exe just passed control over to the existing instance, or something like that, and did not tell Chrome to use this flag.) I realize this is somewhat tricky to do. Ideally, that flag would apply to just the one tab or window that I tried to open, but not to all the other already-existing windows. I have not yet looked at the Chrome/Chromium source code, but I wouldn't be surprised if this is currently implemented as a global setting. Is this feasible? Is there some other way to do what I want? Should I log an enhancement request? Thanks, - Mike Morearty Sr. Computer Scienstist Adobe Systems Inc. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Enabling --disable-hang-monitor for new windows when Chrome is already running
For reference, something similar is done for popups: void NPN_PushPopupsEnabledState(NPP instance, NPBool enabled); void NPN_PopPopupsEnabledState(NPP instance); Perhaps we can do the same thing here: void NPN_PushPluginHangDetectorState(NPP instance, NPBool enabled); void NPN_Pop PluginHangDetectorState(NPP instance); On Fri, Sep 11, 2009 at 2:46 PM, John Tamplin j...@google.com wrote: On Fri, Sep 11, 2009 at 5:24 PM, Darin Fisher da...@chromium.org wrote: I think that is a reasonable feature request. It would be nice however if there were some way to know when to restore the old behavior. Unfortunately, Chrome won't know when you are done. I was thinking something like this for my case (substitute appropriate method names): NPN_SetPluginWarning(false); processSocketMessages(); NPN_SetPluginWarning(true); and trying to call NPN_SetPluginWarning where you didn't request that permission in the manifest would fail. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Enabling --disable-hang-monitor for new windows when Chrome is already running
Another alternative would be a ping type call to say I'm unresponsive, and I mean it. Like a watchdog timer. The plug-in could still effectively be hung, but at least it has to have things together enough to call the watchdog. -scott On Fri, Sep 11, 2009 at 3:37 PM, John Abd-El-Malek j...@chromium.org wrote: For reference, something similar is done for popups: void NPN_PushPopupsEnabledState(NPP instance, NPBool enabled); void NPN_PopPopupsEnabledState(NPP instance); Perhaps we can do the same thing here: void NPN_PushPluginHangDetectorState(NPP instance, NPBool enabled); void NPN_Pop PluginHangDetectorState(NPP instance); On Fri, Sep 11, 2009 at 2:46 PM, John Tamplin j...@google.com wrote: On Fri, Sep 11, 2009 at 5:24 PM, Darin Fisher da...@chromium.org wrote: I think that is a reasonable feature request. It would be nice however if there were some way to know when to restore the old behavior. Unfortunately, Chrome won't know when you are done. I was thinking something like this for my case (substitute appropriate method names): NPN_SetPluginWarning(false); processSocketMessages(); NPN_SetPluginWarning(true); and trying to call NPN_SetPluginWarning where you didn't request that permission in the manifest would fail. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Enabling --disable-hang-monitor for new windows when Chrome is already running
On Fri, Sep 11, 2009 at 6:38 PM, John Abd-El-Malek j...@chromium.org wrote: I presume you're referring to Chrome extensions? I don't see the advantage of making this depend on the plugin being distributed via extensions. How else would an end-user get a plugin installed for Chrome? I don't think you want to tell them to go create a directory if it doesn't exist, and copy the file there, and you don't want to have to write a platform-specific installer to do that either. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Enabling --disable-hang-monitor for new windows when Chrome is already running
On Fri, Sep 11, 2009 at 6:41 PM, Scott Hess sh...@chromium.org wrote: Another alternative would be a ping type call to say I'm unresponsive, and I mean it. Like a watchdog timer. The plug-in could still effectively be hung, but at least it has to have things together enough to call the watchdog. That would be awkward, but doable, as in my case I couldn't use blocking socket reads but would have to do polling so I could call the heartbeat function. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Enabling --disable-hang-monitor for new windows when Chrome is already running
On Fri, Sep 11, 2009 at 6:50 PM, Mike Mammarella m...@chromium.org wrote: Perhaps rather than disabling the hang monitor altogether what that could do is add an additional option to the warning the first time: don't notify me again. If you click that, then it will disable the hang monitor until the plugin is once again responsive and then becomes unresponsive again. (Or maybe even until the plugin terminates.) In the case of debugging something remote, I don't think that buys you anything over the current model unless it is for the lifetime of the plugin. Also, I think it will be annoying to users who expect when they are using debugging the Java code associated with their app that the browser side is going to hang (and better than other browsers where the UI locks up entirely) -- I still think some way for it to always be disabled for the given plugin with the user's consent. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Enabling --disable-hang-monitor for new windows when Chrome is already running
Since the hang dialog comes up in the future after you've shifted your focus elsewhere, if we did any sort of user interaction at all I'd rather the plug-in could say Ask user for permission to disable hang monitor for this context right now. The plug-in hits the breakpoint, calls that function, and on successful return falls into the blocking mode. The browser could cache the response so that the user only has to be asked once per tab (or browser session). -scott On Fri, Sep 11, 2009 at 3:50 PM, Mike Mammarella m...@chromium.org wrote: Perhaps rather than disabling the hang monitor altogether what that could do is add an additional option to the warning the first time: don't notify me again. If you click that, then it will disable the hang monitor until the plugin is once again responsive and then becomes unresponsive again. (Or maybe even until the plugin terminates.) That avoids the need to have a plugin be trusted in any way, but keeps the UI simple unless the plugin knows it wants to display it and get debugged. You'd still have to deal with the dialog once but after that it would get out of your way. --Mike On Fri, Sep 11, 2009 at 3:41 PM, Scott Hess sh...@chromium.org wrote: Another alternative would be a ping type call to say I'm unresponsive, and I mean it. Like a watchdog timer. The plug-in could still effectively be hung, but at least it has to have things together enough to call the watchdog. -scott On Fri, Sep 11, 2009 at 3:37 PM, John Abd-El-Malek j...@chromium.org wrote: For reference, something similar is done for popups: void NPN_PushPopupsEnabledState(NPP instance, NPBool enabled); void NPN_PopPopupsEnabledState(NPP instance); Perhaps we can do the same thing here: void NPN_PushPluginHangDetectorState(NPP instance, NPBool enabled); void NPN_Pop PluginHangDetectorState(NPP instance); On Fri, Sep 11, 2009 at 2:46 PM, John Tamplin j...@google.com wrote: On Fri, Sep 11, 2009 at 5:24 PM, Darin Fisher da...@chromium.org wrote: I think that is a reasonable feature request. It would be nice however if there were some way to know when to restore the old behavior. Unfortunately, Chrome won't know when you are done. I was thinking something like this for my case (substitute appropriate method names): NPN_SetPluginWarning(false); processSocketMessages(); NPN_SetPluginWarning(true); and trying to call NPN_SetPluginWarning where you didn't request that permission in the manifest would fail. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Enabling --disable-hang-monitor for new windows when Chrome is already running
On Fri, Sep 11, 2009 at 6:37 PM, John Abd-El-Malek j...@chromium.org wrote: For reference, something similar is done for popups: void NPN_PushPopupsEnabledState(NPP instance, NPBool enabled); void NPN_PopPopupsEnabledState(NPP instance); Perhaps we can do the same thing here: void NPN_PushPluginHangDetectorState(NPP instance, NPBool enabled); void NPN_Pop PluginHangDetectorState(NPP instance); Sounds fine to me. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Enabling --disable-hang-monitor for new windows when Chrome is already running
On Fri, Sep 11, 2009 at 6:53 PM, Scott Hess sh...@chromium.org wrote: Since the hang dialog comes up in the future after you've shifted your focus elsewhere, if we did any sort of user interaction at all I'd rather the plug-in could say Ask user for permission to disable hang monitor for this context right now. The plug-in hits the breakpoint, calls that function, and on successful return falls into the blocking mode. The browser could cache the response so that the user only has to be asked once per tab (or browser session). I still like the plugin being in control of when the warning is disabled -- let's say the user has code which actually has an infinite loop in JS which gets called by the plugin -- even if I am debugging the Java code and know the plugin will be unresponsive during that time, I still want to catch the hang in what to me is user code. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Enabling --disable-hang-monitor for new windows when Chrome is already running
On Fri, Sep 11, 2009 at 3:54 PM, John Tamplin j...@google.com wrote: On Fri, Sep 11, 2009 at 6:37 PM, John Abd-El-Malek j...@chromium.orgwrote: For reference, something similar is done for popups: void NPN_PushPopupsEnabledState(NPP instance, NPBool enabled); void NPN_PopPopupsEnabledState(NPP instance); Perhaps we can do the same thing here: void NPN_PushPluginHangDetectorState(NPP instance, NPBool enabled); void NPN_Pop PluginHangDetectorState(NPP instance); Sounds fine to me. Me too. As for a ping solution, my response is the same as John's: I could make that work if necessary, but it would be awkward. Having an NPN_... API seems like a cleaner solution. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Enabling --disable-hang-monitor for new windows when Chrome is already running
On Fri, Sep 11, 2009 at 3:44 PM, John Tamplin j...@google.com wrote: On Fri, Sep 11, 2009 at 6:38 PM, John Abd-El-Malek j...@chromium.orgwrote: I presume you're referring to Chrome extensions? I don't see the advantage of making this depend on the plugin being distributed via extensions. How else would an end-user get a plugin installed for Chrome? I don't think you want to tell them to go create a directory if it doesn't exist, and copy the file there, and you don't want to have to write a platform-specific installer to do that either. I don't know quite how the Flash player got into my Chrome, but all I know is, it's there. Although I don't know for sure, I sort of suspect that when Chrome installed, it looked for either (a) all existing Netscape plugins, or (b) just Flash, and enabled it. As far as I know, we (Adobe) don't have any special Chrome extension for installing Flash player. We just have the ActiveX version and the Netscape plugin version. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Enabling --disable-hang-monitor for new windows when Chrome is already running
On Fri, Sep 11, 2009 at 3:44 PM, John Tamplin j...@google.com wrote: On Fri, Sep 11, 2009 at 6:38 PM, John Abd-El-Malek j...@chromium.orgwrote: I presume you're referring to Chrome extensions? I don't see the advantage of making this depend on the plugin being distributed via extensions. How else would an end-user get a plugin installed for Chrome? Through whatever plugin installer they have (i.e. Flash's installer) or the toolkit (i.e. Flash Builder). I don't think you want to tell them to go create a directory if it doesn't exist, and copy the file there, and you don't want to have to write a platform-specific installer to do that either. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Enabling --disable-hang-monitor for new windows when Chrome is already running
On Fri, Sep 11, 2009 at 4:01 PM, Mike Morearty m...@morearty.com wrote: On Fri, Sep 11, 2009 at 3:54 PM, John Tamplin j...@google.com wrote: On Fri, Sep 11, 2009 at 6:37 PM, John Abd-El-Malek j...@chromium.orgwrote: For reference, something similar is done for popups: void NPN_PushPopupsEnabledState(NPP instance, NPBool enabled); void NPN_PopPopupsEnabledState(NPP instance); Perhaps we can do the same thing here: void NPN_PushPluginHangDetectorState(NPP instance, NPBool enabled); void NPN_Pop PluginHangDetectorState(NPP instance); Sounds fine to me. Me too. If this sounds good to you, the next step would be getting a broader discussion with other browser vendors on the plugin-futures mailing list ( https://mail.mozilla.org/listinfo/plugin-futures). As for a ping solution, my response is the same as John's: I could make that work if necessary, but it would be awkward. Having an NPN_... API seems like a cleaner solution. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Enabling --disable-hang-monitor for new windows when Chrome is already running
On Fri, Sep 11, 2009 at 7:31 PM, John Abd-El-Malek j...@chromium.org wrote: If this sounds good to you, the next step would be getting a broader discussion with other browser vendors on the plugin-futures mailing list ( https://mail.mozilla.org/listinfo/plugin-futures). Since the other browsers do not run plugins in a separate thread, they don't have this issue. Is that list still relevant then? -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Enabling --disable-hang-monitor for new windows when Chrome is already running
On Fri, Sep 11, 2009 at 7:28 PM, John Abd-El-Malek j...@chromium.org wrote: Through whatever plugin installer they have (i.e. Flash's installer) or the toolkit (i.e. Flash Builder). So are you suggesting there is a better way to package an NPAPI plugin for Chrome than to build a CRX? On Firefox, NPAPI plugins can be installed via XPI files just like XPCOM components, so it seems appropriate to use the analogous construct here. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Enabling --disable-hang-monitor for new windows when Chrome is already running
On Fri, Sep 11, 2009 at 4:32 PM, John Tamplin j...@google.com wrote: On Fri, Sep 11, 2009 at 7:31 PM, John Abd-El-Malek j...@chromium.orgwrote: If this sounds good to you, the next step would be getting a broader discussion with other browser vendors on the plugin-futures mailing list ( https://mail.mozilla.org/listinfo/plugin-futures). Since the other browsers do not run plugins in a separate thread, they don't have this issue. Is that list still relevant then? Firefox and Safari (at least on Mac) are also moving towards out of process plugins. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Enabling --disable-hang-monitor for new windows when Chrome is already running
So, since Flash is installed by means other than as part of an Extension, does that mean that John Tamplin's suggestion of giving permissions via manifest.json won't work for me? I take it manifest.json is something that only applies to extensions, and not to the other methods of installing a plugin. On the other hand, it seems to me that since (as far as I know) plugins are native code that can do whatever they want, there is no need for giving a plugin special permission to use the new NPN API -- just grant that permission to all plugins. Native plugins can already do just about anything, including read/write access to the filesystem and the Internet, so it doesn't seem necessary for them to need special permission to access this API. On Fri, Sep 11, 2009 at 4:30 PM, John Abd-El-Malek j...@chromium.org wrote: On Fri, Sep 11, 2009 at 4:03 PM, Mike Morearty m...@morearty.com wrote: On Fri, Sep 11, 2009 at 3:44 PM, John Tamplin j...@google.com wrote: On Fri, Sep 11, 2009 at 6:38 PM, John Abd-El-Malek j...@chromium.orgwrote: I presume you're referring to Chrome extensions? I don't see the advantage of making this depend on the plugin being distributed via extensions. How else would an end-user get a plugin installed for Chrome? I don't think you want to tell them to go create a directory if it doesn't exist, and copy the file there, and you don't want to have to write a platform-specific installer to do that either. I don't know quite how the Flash player got into my Chrome, but all I know is, it's there. Although I don't know for sure, I sort of suspect that when Chrome installed, it looked for either (a) all existing Netscape plugins, or (b) just Flash, and enabled it. We crawled the disk/registry for pointers to NPAPI plugins, using the same algorithm that other NPAPI browsers use. You probably already had the plugin from when you used Firefox. If you didn't, we have a plugin installer UI that, once given permission, would download and install it. As far as I know, we (Adobe) don't have any special Chrome extension for installing Flash player. We just have the ActiveX version and the Netscape plugin version. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Enabling --disable-hang-monitor for new windows when Chrome is already running
On Fri, Sep 11, 2009 at 4:52 PM, Mike Morearty m...@morearty.com wrote: So, since Flash is installed by means other than as part of an Extension, does that mean that John Tamplin's suggestion of giving permissions via manifest.json won't work for me? I take it manifest.json is something that only applies to extensions, and not to the other methods of installing a plugin. right On the other hand, it seems to me that since (as far as I know) plugins are native code that can do whatever they want, there is no need for giving a plugin special permission to use the new NPN API -- just grant that permission to all plugins. Native plugins can already do just about anything, including read/write access to the filesystem and the Internet, so it doesn't seem necessary for them to need special permission to access this API. agreed On Fri, Sep 11, 2009 at 4:30 PM, John Abd-El-Malek j...@chromium.orgwrote: On Fri, Sep 11, 2009 at 4:03 PM, Mike Morearty m...@morearty.com wrote: On Fri, Sep 11, 2009 at 3:44 PM, John Tamplin j...@google.com wrote: On Fri, Sep 11, 2009 at 6:38 PM, John Abd-El-Malek j...@chromium.orgwrote: I presume you're referring to Chrome extensions? I don't see the advantage of making this depend on the plugin being distributed via extensions. How else would an end-user get a plugin installed for Chrome? I don't think you want to tell them to go create a directory if it doesn't exist, and copy the file there, and you don't want to have to write a platform-specific installer to do that either. I don't know quite how the Flash player got into my Chrome, but all I know is, it's there. Although I don't know for sure, I sort of suspect that when Chrome installed, it looked for either (a) all existing Netscape plugins, or (b) just Flash, and enabled it. We crawled the disk/registry for pointers to NPAPI plugins, using the same algorithm that other NPAPI browsers use. You probably already had the plugin from when you used Firefox. If you didn't, we have a plugin installer UI that, once given permission, would download and install it. As far as I know, we (Adobe) don't have any special Chrome extension for installing Flash player. We just have the ActiveX version and the Netscape plugin version. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Avoiding DevToolsSanityTest bustages
DevToolsSanityTest flips frequently between enabled and disabled. It seems to be mostly caused by changes in WebKit. I see two nice ways to prevent that: - run the tests upstream on webkit.org bots (probably hard) - run the tests on our webkit canary bot (should be doable) What do you think? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Chromium core principles and multiplatform development?
On Fri, Sep 11, 2009 at 4:28 PM, Jacob Mandelson ja...@mandelson.org wrote: The trybot is restricted access to committers only. I'm not a committer, and as such I don't have access. go/chrometryserver M-A --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] How do you perform tab traversal?
I'm trying to create a simple dialog box following the exam at
http://dev.chromium.org/developers/design-documents/views-windowing.
Note that I'm using views as in a standalone app (I'm not embedding
this dialog in Chromium).
I've added 2 views::Textfields to WindowView, but I can't seem to tab
between them. When I press the tab key, it simply inserts a tab into
the editbox.
Here is what I have:
snip
#pragma once
#include views/controls/textfield/textfield.h
#include views/view.h
#include views/window/dialog_delegate.h
namespace views {
class Label;
class Textfield;
}
class WindowView : public views::View,
public views::DialogDelegate,
public views::Textfield::Controller {
public:
WindowView();
~WindowView();
// Overridden from views::View:
virtual void Paint(gfx::Canvas* canvas);
virtual void Layout();
virtual gfx::Size GetPreferredSize();
// Overridden from views::DialogDelegate:
virtual std::wstring GetWindowTitle() const { return LDemo; }
virtual bool CanResize() const { return true; }
virtual bool CanMaximize() const { return true; }
virtual views::View* GetContentsView() { return this; }
virtual int GetDialogButtons() const { return
MessageBoxFlags::DIALOGBUTTON_OK; }
// Return the view that you want to have initially focused
virtual views::View* GetInitiallyFocusedView();
private:
// Overridden from views::Textfield::Controller:
virtual void ContentsChanged(views::Textfield* sender,
const std::wstring new_contents);
virtual bool HandleKeystroke(views::Textfield* sender,
const views::Textfield::Keystroke
keystroke);
views::Label* label1_;
views::Textfield* textbox1_;
views::Label* label2_;
views::Textfield* textbox2_;
DISALLOW_COPY_AND_ASSIGN(WindowView);
};
/snip
snip
#include kreofusion/misc/context_menu_demo/window_view.h
#include app/gfx/canvas.h
#include base/message_loop.h
#include views/controls/label.h
#include views/standard_layout.h
#include views/widget/root_view.h
WindowView::WindowView()
: label1_(new views::Label(LTextbox 1)),
textbox1_(new views::Textfield()),
label2_(new views::Label(LTextbox 2)),
textbox2_(new views::Textfield()) {
textbox1_-SetController(this);
textbox2_-SetController(this);
AddChildView(label1_);
AddChildView(textbox1_);
AddChildView(label2_);
AddChildView(textbox2_);
}
WindowView::~WindowView() {
MessageLoop::current()-Quit();
}
void WindowView::Paint(gfx::Canvas* canvas) {
views::View::Paint(canvas);
}
void WindowView::Layout() {
const gfx::Rect lb = bounds();
if (lb.IsEmpty())
return;
gfx::Size ps = label1_-GetPreferredSize();
int y = kButtonVEdgeMargin;
label1_-SetBounds(kButtonHEdgeMargin, y, ps.width(), ps.height());
y += ps.height() + kRelatedControlSmallVerticalSpacing;
ps = textbox1_-GetPreferredSize();
textbox1_-SetBounds(kButtonHEdgeMargin, y, lb.width() -
2*kButtonHEdgeMargin, ps.height());
y += ps.height() + kUnrelatedControlVerticalSpacing;
ps = label2_-GetPreferredSize();
label2_-SetBounds(kButtonHEdgeMargin, y, ps.width(), ps.height());
y += ps.height() + kRelatedControlSmallVerticalSpacing;
ps = textbox2_-GetPreferredSize();
textbox2_-SetBounds(kButtonHEdgeMargin, y, lb.width() -
2*kButtonHEdgeMargin, ps.height());
}
gfx::Size WindowView::GetPreferredSize() {
gfx::Size ps = label1_-GetPreferredSize();
ps.set_width(ps.width() + 200);
ps.set_height(ps.height() + 200);
return ps;
}
views::View* WindowView::GetInitiallyFocusedView() {
return textbox2_;
}
// WindowView, private:
void WindowView::ContentsChanged(views::Textfield* sender,
const std::wstring new_contents)
{
}
bool WindowView::HandleKeystroke(views::Textfield* sender,
const views::Textfield::Keystroke
keystroke) {
return false;
}
/snip
What am I doing wrong?
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: Chromium core principles and multiplatform development?
I agree it should be the responsibility of the committer to make sure the code passes the trybots on all platforms (I have in the past made the mistake of thinking the trybots were open to everyone, but they are not). I think many committers will not be willing to go through very many iterations of download/apply patch, send to try bot, sort out whether the errors are due to the patch, send errors back to contributor, so non-committers will likely meet with difficulty when trying to get patches in that they only tried on a single platform. So I don't think it's necessarily a _requirement_ to have all three platforms sitting around but having at least one windows and one posix will greatly expedite the process. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Chromium core principles and multiplatform development?
I generally leave the figure out the errors bit to the committer. Once you've made sure a patch isn't malicious: git checkout origin git cl patch -b theirname 12345 # code review number git try git checkout branch_i_was_working_on You can then point them to the try server build page and say search for your name for errors if it fails. On Fri, Sep 11, 2009 at 6:58 PM, Evan Stade est...@chromium.org wrote: I agree it should be the responsibility of the committer to make sure the code passes the trybots on all platforms (I have in the past made the mistake of thinking the trybots were open to everyone, but they are not). I think many committers will not be willing to go through very many iterations of download/apply patch, send to try bot, sort out whether the errors are due to the patch, send errors back to contributor, so non-committers will likely meet with difficulty when trying to get patches in that they only tried on a single platform. So I don't think it's necessarily a _requirement_ to have all three platforms sitting around but having at least one windows and one posix will greatly expedite the process. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Chromium core principles and multiplatform development?
On Fri, Sep 11, 2009 at 7:03 PM, Evan Martin e...@chromium.org wrote: I generally leave the figure out the errors bit to the committer. I assume you mean the contributor. The problem is then that you are trusting a non-committer to tell you whether to commit, which defeats the purpose of having committer access. Once you've made sure a patch isn't malicious: git checkout origin git cl patch -b theirname 12345 # code review number git try git checkout branch_i_was_working_on You can then point them to the try server build page and say search for your name for errors if it fails. On Fri, Sep 11, 2009 at 6:58 PM, Evan Stade est...@chromium.org wrote: I agree it should be the responsibility of the committer to make sure the code passes the trybots on all platforms (I have in the past made the mistake of thinking the trybots were open to everyone, but they are not). I think many committers will not be willing to go through very many iterations of download/apply patch, send to try bot, sort out whether the errors are due to the patch, send errors back to contributor, so non-committers will likely meet with difficulty when trying to get patches in that they only tried on a single platform. So I don't think it's necessarily a _requirement_ to have all three platforms sitting around but having at least one windows and one posix will greatly expedite the process. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Chromium core principles and multiplatform development?
We could do this instead:gcl try --url http://url/to/patch.diff --email contribut...@email.com --issue rietveldIssueNumber No need to download and apply the patch. - Mohamed Mansour On Fri, Sep 11, 2009 at 10:03 PM, Evan Martin e...@chromium.org wrote: I generally leave the figure out the errors bit to the committer. Once you've made sure a patch isn't malicious: git checkout origin git cl patch -b theirname 12345 # code review number git try git checkout branch_i_was_working_on You can then point them to the try server build page and say search for your name for errors if it fails. On Fri, Sep 11, 2009 at 6:58 PM, Evan Stade est...@chromium.org wrote: I agree it should be the responsibility of the committer to make sure the code passes the trybots on all platforms (I have in the past made the mistake of thinking the trybots were open to everyone, but they are not). I think many committers will not be willing to go through very many iterations of download/apply patch, send to try bot, sort out whether the errors are due to the patch, send errors back to contributor, so non-committers will likely meet with difficulty when trying to get patches in that they only tried on a single platform. So I don't think it's necessarily a _requirement_ to have all three platforms sitting around but having at least one windows and one posix will greatly expedite the process. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
