4 ms·

I understand the reasoning behind this, but this is super annoying, since: 1. I am required to use GWT 2.5.1 for our java webapp 2. I choose to use Chrome on

• cleverjake 12y ago
  Download an older version of chrome, and turn off auto updates.
  • adamrmcd 12y ago
    I had to resort to Firefox 24 on OS X, however I found a Chromium 38 build. Guess that'll do for now. http://www.freesmug.org/chromium http://www.freesmug.org/chromium Could not find any older builds of Chrome for OS X (updated to say I'm on OS X)
    • cleverjake 12y ago
      www.oldversion.com/windows/google-chrome/
    • AlexeyBrin 12y ago
      Maybe this will help http://google-chrome.en.uptodown.com/mac/old http://google-chrome.en.uptodown.com/mac/old (fair warning, I didn't actually tried to download/use any of these).
      • adamrmcd 12y ago
        That's perfect! .. Insta-bookmark! Although I did find Chromium 38 did work to get me back online, this uptodown site will prove useful for other tests requiring full Chrome. Thanks!
    • iSnow 12y ago
      https://www.modern.ie/en-us/virtualization-tools#downloads https://www.modern.ie/en-us/virtualization-tools#downloads
  • tedunangst 12y ago
    Two months from now: "what kind of moron turns off auto update? You deserved to be pwned!"
    • desdiv 12y ago
      This whole thread is based on OP's need for GWT Chrome extension to develop his company's webapp. So presumably OP can have a old Chrome version just for web development and a separate browser for his regular browsing needs. I doubt OP will get pwned by his own company's internal development site.
      • tedunangst 12y ago
        Simultaneously running a safe browser and an unsafe browser and hoping you never open a link in the wrong one seems fraught with peril.
        • waps 12y ago
          google "portable chrome". problem solved.
    • wbkang 12y ago
      Did you actually try it? It's almost impossible to get a hold of the old versions of chrome now. Google tool down almost all of them.
      • tedunangst 12y ago
        No, thankfully I'm not in a position to need to. I'm just commenting on how ludicrous the situation is.
• deleted 12y ago
  [deleted]
• fixermark 12y ago
  This is a par-for-the-course complaint about NPAPI plugins (since they're binary, they're beholden to all the issues of 32-bit 64-bit compatibility, compile to the operating system, etc., etc., etc.). Given the improvements in JavaScript performance and webgl over the past half-decade, it's a small wonder that browser maintainers want to kill NPAPI support as fast as possible. It's a bad experience for them, generally a complex experience for end-users, and essentially a massive hack.
  • pyre 12y ago
    Yes, but then how do you enable support for things that the browser doesn't give you (e.g. someone else talked about pen/stylus input devices)? How do you write something like It'sAllText for Chrome? Current NPAPI-less solutions involve the need to run a separate server to communicate with, which launches the $EDITOR process.
    • JoshTriplett 12y ago
      You don't, by design. You improve the browser to expose the functionality you need with a sandboxed API, or you communicate with a separate program that runs entirely outside the browser. If you want to support a pen or stylus, you add a pen/stylus API to Chrome.
      • nirvdrum 12y ago
        I've been waiting for an API addition, that I had been personally assured by Chromium PM would go through, for 4.5 years. It's needed to support full canvas screenshot functionality in ChromeDriver, so it's not exactly a fringe use case. Given the time it takes for some of this stuff to go through, NPAPI was at least an option. That's the point of a plugin API after all ... so not every use case needs to be accounted for by the parent project. I realize there are security issues and all that. But it's not as simple as hoping Chrome will just add the API you want either, in my experience.
      • hackmiester 12y ago
        If I want to support a pen in Chrome, and the way to do it is to modify Chrome, I am going to give up. I do not have the skill to do that. If I have to learn an entire different programming language to do something, I just don't have the time to do it right now.
• teraflop 12y ago
  I find this kind of astonishing on the part of GWT. NPAPI has been deprecated in Chrome for more than a year, and yet GWT's development mode still depends on it?
  • cromwellian 12y ago
    The GWT team saw this coming a long time ago, that's why we undertook SuperDevMode. It's not just chrome that yanked our APIs, Firefox removed NPAPI, Safari make it incompatible with DevMode, and the rise of mobile devices which don't run plugins, pretty make DevMode useless for mobile development. Our only options are to either ship our own browser fork, like Dartium does and like we used to do with GWT < 2.0 Hosted Mode, or to make Javascript debugging work. We opted for the latter. In GWT 2.7, we can recompile million line apps in seconds, and with Source Maps, and IDE support, you can back some of the original Java debugger experience. In IntelliJ 14 in particular, it works very nicely. Folks are working on Eclipse integration of SourceMap debugging. NPAPI is a security risk and puts restrictions on other parts of the browser internals and how they're represented. We can't prevent Chrome, Firefox, and others removing this API just because of GWT. Ironically, Microsoft might end up supporting this API forever, so GWT DevMode might continue to work with IE.
  • kyrra 12y ago
    SuperDevMode[0] has been a thing for the past year or 2 (which doesn't use the NPAPI plugin). The GWT team just released GWT 2.7 which makes SuperDevMode the default development mode (they also added incremental compilation which rocks). GWT is ready for it, the problem is that most people that use GWT are doing it in "enterprise" world, where upgrading libraries is super painful. [0] http://www.gwtproject.org/articles/superdevmode.html http://www.gwtproject.org/articles/superdevmode.html