GWT Developer Plugin for Chrome on Linux

[dankurka]

Originally reported on Google Code with ID 4325

"Sorry, there is currently no GWT Developer Plugin for Chrome on Linux"

Found in GWT Release: 
2.0.0

Encountered on OS / Browser: 
Ubuntu 9.10 64bit / Google Chrome Beta 4.0.249.30

Detailed description (please be as specific as possible):
I work around it using firefox, but I'd rather stick to one browser for 
development

Shortest code snippet which demonstrates issue (please indicate where
actual result differs from expected result):

Workaround if you have one:

Links to relevant GWT Developer Forum posts:

Reported by spencerg@byu.net on 2009-12-09 19:54:52

---

• Attachment: no-gwt-dev-plugin-chrome-linux.png
  

[dankurka]

I run linux and I want to start developing some Chrome extensions using GWT. This is
a 
*must* have. Now that 2.0 is out the door can this be addressed?

Reported by mark.renouf on 2009-12-12 02:12:00

[dankurka]

I agree. The plugin is a must have.

Reported by ikhwani on 2009-12-12 05:45:03

[dankurka]

outrageous !! 

Reported by naim.mckay on 2009-12-15 14:48:47

[dankurka]

Reported by rice@google.com on 2009-12-15 20:49:28

• Labels added: Category-DevPlugin

[dankurka]

We require the ability to include an NPAPI in the CRX for Linux, which is not yet 
supported.  I believe it has been pushed to Chrome 5, but I am not positive about 
that.

Reported by jat@google.com on 2009-12-15 23:54:12

• Status changed: Accepted
• Labels added: Milestone-Planned, Type-Enhancement

[dankurka]

Must have! 

We need it. The only alternative we have is FF and that is dead-slow and a CPU hog!

Eats up 98+% of CPU and takes ages to render the app. 

Reported by mayank.r.jain on 2009-12-26 03:46:10

[dankurka]

We can't do it until the necessary support is there, but if you are expecting DevMode

in Chrome to be fast it will be longer before it is nearly as fast as the other 
browsers.

Reported by jat@google.com on 2009-12-26 04:08:23

[dankurka]

Does the NPAPI support has to be in CRX? Couldn't it be NPAPI plugin, with CRX (UI)

talking to it?

Reported by dusan.maliarik on 2010-01-11 11:11:48

[dankurka]

Would love to see the dev plugin for chrome.  Just adding my vote here.

Reported by oldCoderException on 2010-01-12 21:20:52

[dankurka]

I agree, I thought it was pretty insane that the GWT debugging tools weren't developed

for Chrome first and foremost.  I suppose it was nice to know that Google wouldn't

force you do download their browser but still... 

Reported by Michael.Vittiglio on 2010-01-17 14:31:09

[dankurka]

Just for the record... the GWT Developer mode plugin *is* available for Chrome on 
Windows and Mac. This issue is for Linux support.

Reported by mark.renouf on 2010-01-17 14:43:36

[dankurka]

@mark.renouf agreed, and that is my problem.  Firefox == SLOW

Reported by Michael.Vittiglio on 2010-01-17 14:50:22

[dankurka]

@mark.renouf, how can I install the developer plugin for chrome on mac osx?.
When I loaded the gwt server on Chrome it couldn't find a suitable plugin.

Reported by francisco.uribe on 2010-01-17 16:49:10

[dankurka]

Any chance we could get a beta quality chrome plugin on linux?

E.g. I'd be willing to give up fancier stuff like debugging support if the basic stuff

worked.

Reported by stephen.haberman on 2010-01-18 16:02:49

[dankurka]

-1 on "E.g. I'd be willing to give up fancier stuff like debugging support if the
basic stuff worked."

Debugging is one of the most important aspects of DevMode... I see little point in
releasing something that will not support that (I'll then find myself using Firefox
anyway)

Reported by uboness on 2010-01-18 16:07:01

[dankurka]

Chrome/Linux (and Mac) support requires three things:
- NPAPI support within CRX on Linux/Mac (a Chrome engineer told me this was scheduled

for Chrome 5)
- http://code.google.com/p/chromium/issues/detail?id=14936
  (this could be worked around by defining different extensions for each platform,
  but that will quickly get ugly when trying to support many different Linux distros
  running Chromium built with different libraries)
- The GWT Developer Plugin currently uses Windows-native dialog code, which would 
need to be rewritten either native for each platform or using a platform-independent

method

Also, we will be changing the way the security dialog works anyway such that it will

require a UI embedded in the browser's chrome anyway, so when we do that we will 
write it in a platform-independent manner.

Once the Chrome pieces are in place, we will schedule the work relative to competing

priorities, so until we get to that point it is hard to make a guess as to when that

will be available.

Also, if you are expecting Chrome DevMode to be faster, you haven't used it on 
Windows.  First, since Chrome runs the NPAPI plugin in a separate process, all 
communication with it has to go over an IPC channel rather than direct calls.  
Second, Chrome has bug http://code.google.com/p/chromium/issues/detail?id=5751 which

means to preserve object identity we have to add an expando onto every JS object, 
which adds another round-trip to the JS interpreter every time we pass an object 
across the wire to the DevMode code server.  Running Showcase in DevMode on 
Chrome/Windows is 2-3 times slower than Firefox on the same machine.  Once the 
referenced bug is fixed we can improve this, but it is unlikely to ever be as fast

(though a faster DOM/JS interpreter might make up for some of the slowdown).

Reported by jat@google.com on 2010-01-18 16:51:21

[dankurka]

must have

Reported by vrnroman on 2010-03-14 17:53:06

[dankurka]

This bug renders devmode unusable for developers that are using HTML5 features that

firefox does not support.

Reported by jonathantwall on 2010-03-18 00:33:51

[dankurka]

Must have

Reported by chihab on 2010-03-22 21:56:21

[dankurka]

It really isn't helpful to just post "must have" -- see the earlier posts about what

preconditions are required before we can implement it.

In case you haven't tried it, you can debug on your Linux machine against a Chrome

Windows instance (I do it all the time running Chrome in a VMware session), so while

it is awkward (and Chrome DevMode is slow for other reasons in addition to the 
additional network overhead), it works just fine.

Reported by jat@google.com on 2010-03-22 22:40:34

[dankurka]

I would like to have it too, but anyway it's not such a big problem. You can debug you

app like you allways do, but just the 'server' side of the code. I've never debuged

'client' side. I've tried this on windows and it is a nice feature. I will wait, no

problem. Keep up the good work guys...

Reported by janez.lavric on 2010-03-28 20:40:22

[dankurka]

It's a must have. I'll try Chrome via wine. If this wont work, then virtual win 
machine for chrome.  Gwt2 rocks.
Thanks  guys.

Reported by UROS.kristan on 2010-03-29 17:09:19

[dankurka]

It seems there there is a performance issues with gwt and firefox on linux. On
average it takes me 2 minutes to see the application running.

I was hoping that chrome would be faster..but not plug in.

Reported by Ali.Laith on 2010-04-11 11:21:25

[dankurka]

It seems there there is a performance issues with gwt and firefox on linux. On
average it takes me 2 minutes to see the application running.

I was hoping that chrome would be faster..but not plug in.

Reported by Ali.Laith on 2010-04-11 11:21:27

[dankurka]

I confirm the performance issue with Firefox (anyone knows if there is any issue for

that?) - it takes a long time here (actually, I ended up creating a war and deploying

it in tomcat, which is way faster).

Will a plugin for chrome have the same issue or is it Firefox-on-GNU/Linux-specific?

Reported by nunojsg on 2010-04-11 12:19:22

[dankurka]

I'm wondering who might be willing to work on a port of the GWT dev mode plugin to 
WebKit. I've been working within the internals of WebkitGtk lately and the JavaScript

API is very reasonable to work with.

Webkit provides all the basic building blocks (including the same developer tools 
chrome uses) to create a simple browser. Since Chrome and Safari are both driven by

webkit it would mostly fill the gap in testing on Linux. It should also greatly 
outperform Chrome due to the single process model.

Thoughts? Is all the source available for such a port? 

Does the plugin use protobufs to talk to GWT? I've used the plain C port of the 
protobuf compiler and it should get the job done.

Reported by mark.renouf on 2010-04-11 16:24:48

[dankurka]

All the source is available -- look in plugins/{common,webkit} for the relevant code.

The protocol is a custom binary protocol, but the common code takes care of all that.

Basically you just need to port the webkit code to be not Mac-specific, and you would

need to come up with some plugin mechanism.

Reported by jat@google.com on 2010-04-11 18:10:17

[dankurka]

We need this plugin, otherwise it doesn't make sense to say GWT tools are platform
independent.
It will be really great if Google releases a SpeedTracer official plugin for firefox
too.. Firefox is present in all linux distros 

Reported by lucky.developer on 2010-04-14 04:01:41

[dankurka]

I really don't know how to say it any plainer.  We plan to have a Chrome plugin for

Linux and Mac, but there are things which must be fixed in Chrome before we can do

that (see the thread for details).  Saying it must be done or GWT is worthless without

it etc etc doesn't help resolve those issues any faster.

Reported by jat@google.com on 2010-04-14 05:51:34

[dankurka]

After gwt google io keynote, decided to try gwt again.
Changed from centos to ubuntu for chrome.
Surprise ! no debug goodness on linux :(
+1 vote on this issue.

Reported by geraldo.ls on 2010-05-22 15:17:44

[dankurka]

Re: comment #30

You can use Firefox, which has GWT Development Mode plugin support. Chrome support
is 
apparently coming as soon as Chrome 5.x is released to the stable channel for Linux.

Since 6.x has started, it can't be too much longer.

Reported by mark.renouf on 2010-05-22 16:09:22

[dankurka]

Chrome 5 Stable for Linux is here: http://googleblog.blogspot.com/2010/05/evolving-
from-beta-to-stable-with.html
Will it work with dev mode?

Reported by m.zdila on 2010-05-26 07:34:37

[dankurka]

I was so happy to see the announcement for stable chromium-5 release, but it seems the

important bits we need for a GWT-Chrome marriage are not there.... :-(

Check the still 'Available' (such an amazingly poor choice of defect status name) required

plugin issue: http://code.google.com/p/chromium/issues/detail?id=14936

Reported by jieryn on 2010-05-26 11:22:47

[dankurka]

Without this plugin, any idea on how can we develop GWT-based apps for ChromiumOS? 

That would possibly give some useful feedback to ChromeOS Google team...

Reported by fix.kowalski on 2010-05-26 14:46:03

[dankurka]

@fix.kowalski: I don't know what APIs are present in Chrome as running in ChromeOS vs

Chrome/Windows, but you presumably you should be able to debug most of the app in 
Chrome/WIndows.

Reported by jat@google.com on 2010-05-26 14:49:45

[dankurka]

From Chromium devs: Comment #16 on issue 14936 by mpcomplete@chromium.org: Define manifest

format for NPAPI across platforms
http://code.google.com/p/chromium/issues/detail?id=14936

This has been low priority since there is a simple workaround. Just add a plugin
entry for each platform:
 "plugins": [
   { "path": "plugin-windows.dll" },
   { "path": "plugin-linux.so" },
   { "path": "plugin-mac.so" }
 ]

I'm actually inclined to mark this as WontFix unless that doesn't work for some
reason.

Reported by jieryn on 2010-05-28 00:58:55

[dankurka]

But where do we get the linux library? Is it okay to copy the file from a Firefox
plugin? I suppose it isn't, as those are different rendering engines. (Anyway I tried
that here (GNU/Linux, 64 bits), and it didn't work - if it really should work, which
versions of plugins should I mix and on which version of chrome would it work?)

Reported by nunojsg on 2010-05-28 09:14:55

[dankurka]

If marking it WontFix and passing your work around on to the proper parties at Google
will get them to build the 
needed plugins, then YES PLEASE, mark it WontFix. Is there a way for us to help you
test your workaround? Using 
dummy plugins to prove that it works?

(NOTE: I'm waiting for the Mac plugin - affected by the same issue. http://code.google.com/p/google-web-
toolkit/issues/detail?id=4432 )

Reported by Steven.Jay.Cohen on 2010-06-03 08:13:35

[dankurka]

Is this related? http://groups.google.com/group/google-web-
toolkit/browse_thread/thread/33a5b323eb0f3dde?hl=en#

Reported by Steven.Jay.Cohen on 2010-06-03 08:22:38

[dankurka]

A GWT plugin for chrome is a must, because firefox is dead slow on HTML5.

Reported by wglas85 on 2010-06-03 15:54:17

[dankurka]

I'm toying with the idea of porting the GWT plugin code to a simple patch against 
webkit-gtk. Much of the JavaScriptCore API is the same, my biggest hurdle is the rest

of the Safari plugin is written in Objective-C which I'm not familiar with. The wire

protocol handler is also written in C++ though I believe I could re-implement that

without too much trouble.

The value here for me is developing GWT code against cutting edge or experimental 
APIs which first appear upstream in the Webkit codebase. 

It sounds like it may be not too long before a Chrome plugin is available, but this

would useful on it's own. If so, reply offline so as not to pollute the comment list.

Am I nuts to consider this? Would anyone consider helping with such an endeavor?

Reported by mark.renouf on 2010-06-03 16:39:55

[dankurka]

any updates on this issue? Dev mode for chromium/chrome linux would be really helpful.

Reported by ian.ballester on 2010-06-08 07:19:06

[dankurka]

Man, this was disappointing...

Reported by igolovic on 2010-06-10 05:45:51

[dankurka]

The first post was:  Dec 09, 2009 today Jun 22, 2010 and we still waiting for the Plugin.....
this is so ironic, gwt have plugins for other browser but not for the browser for the
same company... buuu WE NEED IT.

MUST HAVE.....

Reported by maxtorzito on 2010-06-22 05:39:03

[dankurka]

What about the freaking PLUGIN!?!?! whats the story? 

Reported by erez.vaxman on 2010-07-07 06:54:19

[dankurka]

From mark.renouf: "Just for the record... the GWT Developer mode plugin *is* available
for Chrome on 
Windows and Mac."

It is?  Where?  When you try to go to a dev mode project it tells me there's no plugin...

Reported by david@sogeeky.net on 2010-07-07 20:53:55

[dankurka]

Sorry, I was mistaken when I posted that comment, unfortunately I cannot delete or edit.
No plugin for Mac or Linux :-(

To everyone whining. The ball has been in the Chrome/Chromium side the whole time on
this one. As has been mentioned numerous times, the GWT team is awaiting resolution
of some specific support in Chrome for supporting platforms other than Windows.

Something to do with packaging the native plugin within a CRX? Though, it seems to
me work should be proceeding on this at least, the packaging can get sorted out later...
If there were a native plugin.so we could manually install to get GWT support, people
would be much happier to wait for a proper solution to the plugin.

Does NPAPI Pepper support help with this? I believe it's implemented since the "embedded"
flash support makes use of it, right?

https://wiki.mozilla.org/NPAPI:Pepper

Reported by mark.renouf on 2010-07-07 21:31:58

[dankurka]

> If there were a native plugin.so we could manually install to get GWT support, people
would be much happier to wait for a proper solution to the plugin.

Agreed.  I could care less if it's neatly packaged up into a single package, I'd be
perfectly happy manually installing it -- if it exists.  Does it?  If so, where can
we get it and how would we manually install it?

Reported by david@sogeeky.net on 2010-07-07 21:38:52

[dankurka]

It is on our Q3 plans to get this done, whether it involves making changes to Chrome
ourselves or not.

Reported by jat@google.com on 2010-07-07 21:44:56

• Labels added: Milestone-2_1
• Labels removed: Milestone-Planned

[dankurka]

+1 for the GWT plugin on Mac OSX (and the Speed Tracer!)

it's a pity to see that it is always the development for windows that is ahead :(

Reported by o.voortman on 2010-07-08 08:17:21