GWT Developer Plugin on Safari 5.1 (OS X Lion 10.7) doesn't load
Eric Ridge
work with Safari 5.1/OS X 10.7? Safari refuses to load it, and I can
find no indication as to why.
(fortunately, I keep around a copy of Safari 4.0.5 so I can keep working.)
Any insight will be greatly appreciated!
eric
alexkrishnan
Safari 5.1 that came out with Lion today. My workaround is using
chrome.
Eric Ridge
If you go to Help --> Installed Plug-ins, it's not listed.
Its "Info.plist" looks just fine, so I'm thinking maybe the Safari
plugin API changed with 5.1. There's nothing in any of the OS logs
(/var/log/system.log, etc) where Safari is complaining.
Maybe I'll try to hunt down the plugin sources and re-compile it and
see what happens.
eric
> --
> You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
> To post to this group, send email to google-we...@googlegroups.com.
> To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
>
>
Shawn Brown
It broken on SnowLeopard too after upgrading to Version 5.1 (6534.50)
Shawn
Shawn Brown
>> It broken on SnowLeopard too after upgrading to Version 5.1 (6534.50)
I saved the .dmg and ran the GWT Dev Plugin.mpkg which showed it
installed, but it doesn't show up as installed after re-launching
Safari.
7/21/11 3:44:46.041 PM installd: PackageKit: ----- Begin install -----
7/21/11 3:44:46.736 PM installd: Installed "Google Web Toolkit
Developer Plugin" ()
7/21/11 3:44:46.748 PM installd: PackageKit: ----- End install -----
7/21/11 3:44:47.046 PM Installer: Removing temporary directory
"/var/folders/78/qxddxy2j5y153vbgxv22x4_40000gn/T//Install.3352RVZOtz"
7/21/11 3:44:47.049 PM Installer: Finalize disk "Macintosh HD"
7/21/11 3:44:47.050 PM Installer: Notifying system of updated components
7/21/11 3:44:47.050 PM Installer: **** Summary Information ****
7/21/11 3:44:47.050 PM Installer: Operation Elapsed time
7/21/11 3:44:47.050 PM Installer: -----------------------------
7/21/11 3:44:47.050 PM Installer: zero 0.01 seconds
7/21/11 3:44:47.050 PM Installer: disk 0.02 seconds
7/21/11 3:44:47.050 PM Installer: install 1.09 seconds
7/21/11 3:44:47.050 PM Installer: -total- 1.12 seconds
7/21/11 3:44:47.235 PM Installer: IFDInstallController 83025890 state = 5
7/21/11 3:44:47.235 PM Installer: Displaying 'Install Succeeded' UI.
This didn't work for either SnowLeopard or Lion
Shawn
Eric Ridge
> Maybe I'll try to hunt down the plugin sources and re-compile it and
> see what happens.
Well, that didn't help. What I found is that the little "Browser.app"
testing app that comes with the plugin source does indeed load the
plugin (but then there's crashes in OophmWebScriptObject.mm):
GNU gdb 6.3.50-20050815 (Apple version gdb-1705) (Fri Jul 1 10:50:06 UTC 2011)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin".sharedlibrary
apply-load-rules all
Waiting for process 'Browser' to launch.
Attaching to process 31073.
warning: This configuration supports "Darwin" but is attempting to load
an executable of type i386:x86-64 which is unlikely to work.
Attempting to continue.
`/usr/lib/dyld' has changed; re-reading symbols.
warning: Inconsistent DBX_SYMBOL_SIZE (nlist record size was 16, is
now 12 with /usr/lib/dyld)
Pending breakpoint 1 - ""OophmWebScriptObject.mm":121" resolved
Current language: auto; currently objective-c++
(gdb) bt
#0 -[OophmWebScriptObject
connectWithUrl:withSessionKey:withHost:withModuleName:withHostedHtmlVersion:]
(self=0x6c03fd30, _cmd=0x6c03f7b0, url=0x0, sessionKey=0x0, host=0x0,
moduleName=0x0, hostedHtmlVersion=0x0) at OophmWebScriptObject.mm:121
#1 0x9636768d in __invoking___ ()
#2 0x963675c9 in -[NSInvocation invoke] ()
#3 0x9b7c1b47 in JSC::Bindings::ObjcInstance::invokeObjcMethod ()
#4 0x9b7c16b1 in JSC::Bindings::ObjcInstance::invokeMethod ()
#5 0x9b7c15ac in JSC::callRuntimeMethod ()
#6 0x90e9a64c in cti_op_call_NotJSFunction ()
Previous frame inner to this frame (gdb could not unwind past this frame)
(gdb)
and I can't figure out why all the arguments to connectWithUrl are null.
However, none of that seems to matter since when you actually install
the plugin into either ~/Library/Internet Plugins, or
/Library/Internet Plugins, Safari still refuses to load it.
I don't know what to think. :(
eric
Darmawan
eric
Eric Ridge
>
> Looks like it's because the Webkit Plugin API is deprecated in Safari 5.1
> ( regardless the OSX version ) ? Can anybody help to confirm this ?
> Thanks.
I don't think that's the case per se. The Plugin API still exists
within the WebKit.framework. I saw some rumblings on the 'net about
the API being deprecated, but couldn't find anything definitive on
Apple's developer website.
I'm no Cocoa expert, so there's probably a thousand reasons why I
failed, but I couldn't even get the "WebKitPluginStarter" example from
developer.apple.com to work. Looks like it was created long ago, so
maybe it's bit-rotted. Safari did load it (unlike the GWT plugin),
but it didn't actually work.
I really wish somebody from the GWT development team would see this
thread (and issue #6601
http://code.google.com/p/google-web-toolkit/issues/detail?id=6601) and
reply.
Lion & Safari 5.1 are definitely brand new, but I find it hard to
believe that nobody on the GWT team was involved with the developer
previews of Lion.
eric
Jeff Schnitzer
eric
Eric Ridge
the WebKit plugin API is no longer supported as of 10.7 (which I
assume also means Safari 5.1, regardless of OS version):
It says:
Note: As of Mac OS X v10.7, the legacy WebKit plug-in architecture is
no longer supported. Going forward, you must convert WebKit plug-ins
to Netscape-style plug-ins or Safari Extensions.
So now that I know what's going on for sure (and have documentation
reference), I'm going to attempt to convert the plugin. Wish me luck.
eric
David Chandler
why the GWT team hasn't done it yet).
We're currently evaluating how to handle the recent Firefox as well as
Safari changes going forward. The FF change is especially onerous as
it now requires engineering effort every 6 weeks to stay up to date.
/dmc
--
David Chandler
Developer Programs Engineer, GWT+GAE
w: http://code.google.com/
b: http://turbomanage.wordpress.com/
b: http://googlewebtoolkit.blogspot.com/
t: @googledevtools
Jeff Chimene
> (snip)
>
> We're currently evaluating how to handle the recent Firefox as well as
> Safari changes going forward. The FF change is especially onerous as
> it now requires engineering effort every 6 weeks to stay up to date.
>
> /dmc
>
I'd like to suggest bringing this up with the rest of the community as
soon as possible. It's clear that Mozilla isn't going to back down on
this decision, and the impact on the GWT plugin will be substantial.
David Chandler
are open source, so if someone has interest in keeping them up to
date, we're all ears...
/dmc
Eric Ridge
> Good luck, Eric :-) It likely requires non-trivial changes (which is
> why the GWT team hasn't done it yet).
It's not clear yet what'll be required. It looks like whoever wrote
the current plugin did a pretty decent job of separating concerns.
I'm currently playing with one of the WebKit example NPAPI plugins
(from webkit.org)... and that at least works.
I would like to say that it really stinks that nobody from the GWT
team warned us that Safari 5.1 + OOPHM doesn't work. It's debatable
whether or not it's my responsibility to keep up with this stuff, but
it's definitely the GWT team's responsibility to at least communicate
such things to their users.
Part of me wants to say f*ck it and use FF, but frankly, I don't like
FF. Devmode is painfully slow in Chrome, and I'm definitely not
switching to Windows.
> We're currently evaluating how to handle the recent Firefox as well as
> Safari changes going forward. The FF change is especially onerous as
> it now requires engineering effort every 6 weeks to stay up to date.
Hire somebody.
eric
Jeff Chimene
> Sure, do you mean the GWT community or some other? Dev mode plugins
> are open source, so if someone has interest in keeping them up to
> date, we're all ears...
>
> /dmc
The former.
I was looking around in the repository, but didn't see it (them). But I
have to admit I didn't spend more than 5 minutes searching.
Anyway, the maintenance of the FF plugins has exigent nature that isn't
shared by most of the GWT baseline. Can the "relaxed" nature of most
Open Source development work with such a time-constraint? That's why I'm
suggesting a discussion about this topic.
macagain
On Monday, July 25, 2011 4:29:18 PM UTC-6, Eric B. Ridge wrote:
On Mon, Jul 25, 2011 at 5:55 PM, David Chandler <drfib...@google.com> wrote:
> Good luck, Eric :-) It likely requires non-trivial changes (which is
> why the GWT team hasn't done it yet).
I would like to say that it really stinks that nobody from the GWT
Jurriaan Mous
We fixed it with downloading http://support.apple.com/downloads/Safari_4_0_3
and extracting Safari.app from the dmg its Applications folder with a
trial of http://www.macupdate.com/app/mac/6812/pacifist
It works both on Snow Leopard as on Lion. You can rename the old
Safari so you can have both together on one system. The App uses the
new Webkit on the system so it is only the old Safari user interface
shell which uses the old Webkit API.
Eric Ridge
> A workaround:
>
> We fixed it with downloading http://support.apple.com/downloads/Safari_4_0_3
> and extracting Safari.app from the dmg its Applications folder with a
> trial of http://www.macupdate.com/app/mac/6812/pacifist
Hey, that works. And it also works in conjunction with the Flash
plugin (which is important for our project). Thanks!
eric
Eric Ridge
> On Mon, Jul 25, 2011 at 5:55 PM, David Chandler <drfib...@google.com> wrote:
>> Good luck, Eric :-) It likely requires non-trivial changes (which is
>> why the GWT team hasn't done it yet).
>
> It's not clear yet what'll be required. It looks like whoever wrote
> the current plugin did a pretty decent job of separating concerns.
What's required is a ton of work. The current plugin is tied directly
to the JavaScriptCore API which, as best I can tell, can't be made
available via the NPAPI. (if it could, the conversion would likely be
straight forward).
And since Safari 5.1 (WebKit2) runs plugins out-of-process, it makes
me think that the plugin would be terribly slow... similar to Chrome's
performance. But that's just conjecture.
If I had 2-3 weeks I could definitely get the plugin working, but
alas, hacking GWT Plugins is not in my RealJob description. Jurriaan
Mous' workaround is good enough for now.
And David, for what it's worth, the fact that this "likely requires
non-trivial changes" is all the more reason why the GWT team should
have started on it already. GWT is billed as being cross-platform,
and y'all have definitely put in tremendous effort making that true.
You've created something extremely powerful and developed a very large
and dedicated community. With that comes responsibility.
Your other email that said "Dev mode plugins are open source, so if
someone has interest in keeping them up to date, we're all ears..." is
a bit disingenuous. Sure, all of GWT is open source, but frankly, the
community views it as being developed and maintained solely by Google.
If what you're saying is that Google isn't going to maintain the
plugins anymore, that's a pretty big deal. But if you're just
complaining that the GWT team doesn't have the internal resources to
keep pace with browser vendors, then my previous suggestion stands...
hire someone to do that work.
eric
David Chandler
Thank you for your investigation and for dialing down the tone a bit.
I'm pleased that the GWT team has done such a good job in the past
that you've come to expect not only a great, free toolkit, but also
updates delivered within days of new browser and OS releases. Unfortunately,
the Google instant search team hasn't yet tackled the instant dev mode
plugin problem ;-) The recent FF and Safari changes caught us by
surprise. The timing is particularly bad as lots of folks are on
summer vacation, and hiring doesn't happen overnight. Rest assured
that engineering management is aware of the "plugin crisis" and we are
working to address the situation; however, I cannot give you an ETA.
Please be patient.
Also, please be advised that I will be on vacation for the next couple
weeks. I will not be reading this group during that time, and very
likely no one will be responding to general GWT inquiries during that
time, although engineers will continue to chime in on specific
technical issues as always. New member moderation may also be slower
than usual. It is not typical to announce vacation on the GWT group,
but I wanted to give Thomas Broyer a message to link to in response to
any "Why hasn't the GWT team responded to X" threads that may emerge.
Thanks for all you do, Thomas :-)
Best,
/dmc
--
Eric Ridge
> Eric,
>
> Thank you for your investigation and for dialing down the tone a bit.
I'm just disappointed. I'm sure all of the Mac users out there feel a
bit abandoned right now.
> I'm pleased that the GWT team has done such a good job in the past
> that you've come to expect not only a great, free toolkit, but also
> updates delivered within days of new browser and OS releases.
It's not that I expect updates within days of a new browser. My
expectation is that the GWT team communicate with us about trouble
spots *before* new browser/OS releases. There's a big difference
there.
Also, my company would pay real American dollars for GWT, but the
level of service would have to be higher. GWT completely changes the
web-development game. Sadly, "devmode", while probably GWT's greatest
strength, is also its biggest weakness.
> engineering management is aware of the "plugin crisis" and we are
> working to address the situation; however, I cannot give you an ETA.
> Please be patient.
As an outsider looking in, I hope that "engineering management" is
more aware that GWT has a community to support and that more could do
more to appease the natives. There's a lot of companies that need to
make strategic decisions based on technical details, such as the
current state of GWT, its plugins, its APIs, its future roadmap.
The GWT team doesn't seem to provide a lot of insight into this,
despite the seemingly never-ending questions popping up on this
mailing list.
> Also, please be advised that I will be on vacation for the next couple weeks.
Enjoy!
eric
Thomas Broyer
> It is not typical to announce vacation on the GWT group,
> but I wanted to give Thomas Broyer a message to link to in response to
> any "Why hasn't the GWT team responded to X" threads that may emerge.
Ha! Pretty bad timing actually: I'll be on vacation too until mid-August.
> Thanks for all you do, Thomas :-)
You're welcome! It's such a pleasure to work with GWT everyday for
more than 3 years now, compared to other things I could have to do at
work (PHP, ExtJS, etc.), and despite what some of my teammates
(unfortunately used to PHP and ExtJS) could say.
I wouldn't trade GWT for anything (but Closure), and the best way to
support a project is to send feedback, contribute patches, and help
the community.
alexkrishnan
clearer when I'm using the older Safari and the newer Safari.
I downloaded the WebKit nightly build (webkit.org) then copied the
gold-rimmed icon from webkit to the old version of Safari, so that I
can visually tell the old and new version apart in my dock. The
easiest way to do this is to select the app in the finder and say Get
Info. Then simply select the icon by clicking on it in the info pane,
hit Command-C, then Command-V it to the icon for your older version of
Safari in its Get Info pane.
If you want to take it one step further and change the app name in the
menubar so it says something like "Safari OLD" instead of "Safari",
select the old version of Safari in the Finder, right click on it, and
choose "Show Package Contents". Then navigate to Contents, and edit
the plist called "Info.plist". Open it in any text editor that will
show you the text source, not the tree (i.e. not xCode; personally I
prefer TextWrangler but even vim would do) and edit "Safari" on line
442 to whatever string you want to appear in the menubar. I haven't
discovered any stability issues from this, but no guarantees. ;)
Enjoy!
-Alex
Raphael André Bauer
> A workaround:
>
> We fixed it with downloading http://support.apple.com/downloads/Safari_4_0_3
> and extracting Safari.app from the dmg its Applications folder with a
> trial of http://www.macupdate.com/app/mac/6812/pacifist
>
> It works both on Snow Leopard as on Lion. You can rename the old
> Safari so you can have both together on one system. The App uses the
> new Webkit on the system so it is only the old Safari user interface
> shell which uses the old Webkit API.
Great catch - thanks :)
Raphael
>
> On 20 jul, 21:28, Eric Ridge <eeb...@gmail.com> wrote:
>> Is there a trick to get the currently-available-for-Safari plugin to
>> work with Safari 5.1/OS X 10.7? Safari refuses to load it, and I can
>> find no indication as to why.
>>
>> (fortunately, I keep around a copy of Safari 4.0.5 so I can keep working.)
>>
>> Any insight will be greatly appreciated!
>>
>> eric
>
> --
> You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
> To post to this group, send email to google-we...@googlegroups.com.
> To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
>
>
--
inc: http://ars-machina.raphaelbauer.com
tech: http://ars-codia.raphaelbauer.com
web: http://raphaelbauer.com
macagain
Steven Jay Cohen
alexkrishnan
Steven Jay Cohen
joergviola
I found it even simplier to install the 4.05 version from
http://michelf.com/projects/multi-safari/
> We fixed it with downloadinghttp://support.apple.com/downloads/Safari_4_0_3
