Exception reporting is broken in GWT: would you support a kickstarter project to fix it?

[Alex Epshteyn]

One of the big problems with deployed GWT apps has always been the
impossibility of tracing JavaScript exceptions back to the Java source
code. What we need is a true equivalent of Java stack traces.

There was an effort made by the GWT team a couple years ago to solve
this problem ( https://code.google.com/p/google-web-toolkit/wiki/WebModeExceptions
), and it was a good start, but unfortunately they gave up without
producing an adequate solution. If you've ever tried to use the
compiler.emulatedStack.recordLineNumbers setting, you know that it is
badly broken: the line numbers and file names reported in the stack
traces are incorrect most of the time, while the the resulting
compiled JavaScript is 70-90% larger than the original. The way this
feature is currently implemented, the compiler puts instrumentations
in the wrong places most of the time, doesn't do enough to optimize
for code size, and does not provide enough information via symbol maps
for StackTraceDeobfuscator. On Chrome, theoretically we could use
compiler.useSourceMaps instead, but that feature is badly broken too.

I have spent the last 2 months working on this problem full time, and
I almost have the perfect solution ready. But I'm an indie developer,
and I can't really afford to go unpaid much longer, because I've
already put business aside for two months to work on this (originally
I thought it would take a week, but I kept finding more and more bugs
and tricky problems to solve, which is why I'm guessing the original
developers gave up on seeing this project through to fruition).

If I started a crowdfunding campaign to help me fund this work to
completion, would you or your employer be willing to contribute? The
original Google Atlanta team did an amazing job developing GWT for 10+
years, but those guys are all gone, and Google has not had a dedicated
team working on GWT since last summer, so I think it will be up to the
user community to fund its future development from now on.

My goal is perfect JavaScript stack traces with exact Java line
numbers, with only a 50-60% output size increase and similar
performance metrics. For browsers that support sourcemaps (only
Chrome for now), there will be no output size increase at all, because
I intend to fix all the bugs associated with the
compiler.useSourceMaps feature as well.

[Jens]

I dont think you will get paid for it, because:

1.) Its somewhat not in the spirit of open source software

2.) Your patch must go through review and there is no guarantee that it will be committed

3.) GWT will remove IE6/7 support soon and probably in 2014 also IE8 support. Also Opera moves to WebKit. That means that there is probably no need for StackTrace emulation anymore in the near future as modern browsers provide the relevant information.

-- J.

[Alex Epshteyn]

Thanks for your comment.  Let me respond to your points:

1) I've seen this point discussed before, and the standard counter-argument is that the spirit of OSS is free as in "freedom," not "beer."  Lots of developers get paid to work on OSS projects.

2) This is actually one of the reasons I'm thinking about raising funds.  I am already on the verge of using my patch inside my own GWT-based app, but if I get some funding I'd be able to justify taking the extra time to make sure the patch will pass the review process.

3) I must point out that your third argument is not in the spirit of GWT, which aims to support as many browsers as possible.

As of today, you will not get good stack traces with GWT on any modern browser, including WebKit.  By "relevant information", I assume you mean sourcemaps support.  Well, Chrome is the only browser that currently supports sourcemaps but GWT's existing support for generating stack traces with that information is very buggy, and this is one of the things I'm working on improving.  I'm also not optimistic that sourcemaps will achieve universal support any time soon, if ever.

-- J.

--
You received this message because you are subscribed to a topic in the Google Groups "Google Web Toolkit" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/hP8cQ7AdDUc/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to google-web-tool...@googlegroups.com.
To post to this group, send email to google-we...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Alex Epshteyn]

Correction: when I said that a browser needs to support sourcemaps to generate accurate stack traces, that wasn't entirely accurate.  What a browser needs to support is the "stack" property of exception objects, which provides a JavaScript stack trace with both line and column numbers.  It's the GWT compiler that uses a sourcemap to derive original Java line numbers and filenames from the browser-provided line and column numbers.  This functionality is currently broken in GWT, however, and Chrome is currently the only browser that provides column numbers.  And even if more browsers add column info in the future, it's almost certain that their stack trace formats will all be different, so we'll have to patch GWT every time a new browser adds the support.  My proposed project will leave us in good shape to be able to do that easily.

[Thomas Broyer]

On Wednesday, May 22, 2013 11:53:47 PM UTC+2, Alex Epshteyn wrote:

Thanks for your comment.  Let me respond to your points:

1) I've seen this point discussed before, and the standard counter-argument is that the spirit of OSS is free as in "freedom," not "beer."  Lots of developers get paid to work on OSS projects.

2) This is actually one of the reasons I'm thinking about raising funds.  I am already on the verge of using my patch inside my own GWT-based app, but if I get some funding I'd be able to justify taking the extra time to make sure the patch will pass the review process.

+1 to those 2 points.

 

3) I must point out that your third argument is not in the spirit of GWT, which aims to support as many browsers as possible.

That's not entirely true. GWT only ever supported the 4 major browser engines: Trident (IE), WebKit (SquirrelFish / V8; aka Safari / Chromium), Gecko (Firefox) and Presto (Opera).

Jens is right: we'll soon remove support for IE6 and 7, and then for IE8 (not long after MS drops support for WinXP).

GWT never really "supported" Opera, and the level of support was only against the latest version. Now that Opera is moving from Presto to Chromium, that means one less platform to support in the very near future (by the next GWT release, but we'll probably keep the "opera" permutation along for one more release).

As of today, you will not get good stack traces with GWT on any modern browser, including WebKit.  By "relevant information", I assume you mean sourcemaps support.  Well, Chrome is the only browser that currently supports sourcemaps but GWT's existing support for generating stack traces with that information is very buggy, and this is one of the things I'm working on improving.  I'm also not optimistic that sourcemaps will achieve universal support any time soon, if ever.

Chromium has it for a while (hence Chrome –all platforms–, Opera for Android –though what matters is the remote debugger, not the browser– and Opera.next), and Firefox is starting to roll it out [1,2] in 23 (currently Aurora channel) and I'm told the next Safari should have it too [3].

Will IE ever have it? I believe so, particularly now that MS is pushing languages that compile to JS (TypeScript, which can generate sourcemaps). Obviously that would only be available in IE11 (or later), but it seems like it would be possible to have support in your IDE with the help of an IE plugin [4] for IE8/9/10 (would it work in Windows 8 though?)

That said, source maps support in the browser is related to, but different from stack trace resymbolization.

[1] https://hacks.mozilla.org/2013/05/firefox-developer-tool-features-for-firefox-23/

[2] https://hacks.mozilla.org/2013/05/compiling-to-javascript-and-debugging-with-source-maps/

[3] http://stackoverflow.com/questions/16446114/is-it-possible-to-enable-javascript-source-maps-in-safari-6

[4] http://wiki.eclipse.org/JSDT/Debug/IE

[Alex Epshteyn]

Hi Thomas,

Thanks for chiming in and providing the extra info.  Good to know.

I'd like to ask, however, the reasons for planning to remove support for IE6/7/8?  Why would we do that?  It's already there and doesn't require too much maintenance.

As of today, nearly 8% of my site's visitors are on IE8 and close to 1% are still on IE7.  These are pretty big numbers for a high traffic website, and would translate into lost revenue if the browsers weren't supported.  I can't imagine Google pulling support for a browser with that kind of usage for one of its products. .  Here's the full data: https://docs.google.com/spreadsheet/ccc?key=0AvMlWdpkpAA6dGdpa3lsZTVQWl9qcFJrWmZCZ0ZZb0E#gid=0

Also, as you guys can see from the data, stack emulation is still required for 54% of my site's traffic.

While I'd like to see users upgrading to the latest browsers as much as any developer, let's be realistic: WinXP is not going away any time soon (Microsoft dropping support for it isn't going to make people like my dad go out and buy a new computer).  Google Analytics is shows that 80% of my users are on Windows and 21% of those are still on Windows XP: that is a very big number!

--

[Juan Pablo Gardella]

I agree on do not remove IE7 and IE8. A lot of user still using them.

2013/5/23 Alex Epshteyn <alexander...@gmail.com>

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-tool...@googlegroups.com.

[Jens]

I'd like to ask, however, the reasons for planning to remove support for IE6/7/8?  Why would we do that?  

To simplify the code base and moving on (HTML 5) I would say. 

JQuery for example already did that transition. JQuery 2.0 does not support IE6-8 anymore but they still maintain JQuery 1.9.x for people that still need IE6-8 browser support. In terms of GWT you can still use the last version that supports IE6-8 and then decide yourself when its time to move to a newer GWT version for your site.

-- J.

[Alex Epshteyn]

Fair enough, but I'm curious to know why leaving the code that supports legacy browsers would interfere with implementing new features.  For example, if you want to implement a new widget called XPanel, it think it's perfectly fine to say that this widget doesn't support IE6/7/8, and leave it up to userland to chose whether to use the new widget and how to work around it for new browsers.

Do you have a specific example?  I'm curious.

[Jens]

Do you have a specific example?  I'm curious.

Existing widgets should also work great on mobile devices, its not just about writing new widgets. 

Its also not just about widgets in general. For example there is currently an issue in GWT-RPC where only IE9 has a memory leak because GWT-RPC uses eval() to parse the server response and IE9 keeps everything eval'd in memory. Slightly changing the server code and switching to JSON.parse() on the client would solve the problem, but IE6/7 do not support JSON.parse(). So to fix this issue for IE9 the server serialization needs to figure out which IE version is talking to the server and then generate different responses (either JS or JSON). Targeting different browsers on client side is easy (deferred binding) but this time the server must target different browser versions as well. So its more complicated than it could be.

https://code.google.com/p/google-web-toolkit/issues/detail?id=5736

https://gwt-review.googlesource.com/#/c/2900/

I think thats a good example where IE6/7 support costs more development resources although you know that IE6/7 doesn't really play a big role anymore. Microsoft recommends to not use them anymore and 2014 they will stop supporting IE6-8 as Windows XP extended support ends in April 2014.

So would you invest a lot of work today in supporting browsers whose support officially ends in less than a year? Probably not. Its a good time now to slowly phasing out IE6/7 and later IE 8 support.

-- J.

[Thomas Broyer]

On Thursday, May 23, 2013 11:11:22 PM UTC+2, Alex Epshteyn wrote:

Hi Thomas,

Thanks for chiming in and providing the extra info.  Good to know.

I'd like to ask, however, the reasons for planning to remove support for IE6/7/8?  Why would we do that?  It's already there and doesn't require too much maintenance.

Have a look at the I/O talk: http://youtu.be/Ul-LbfkJ-tw?t=10m20s

 

As of today, nearly 8% of my site's visitors are on IE8 and close to 1% are still on IE7.  These are pretty big numbers for a high traffic website, and would translate into lost revenue if the browsers weren't supported.  I can't imagine Google pulling support for a browser with that kind of usage for one of its products. .  Here's the full data: https://docs.google.com/spreadsheet/ccc?key=0AvMlWdpkpAA6dGdpa3lsZTVQWl9qcFJrWmZCZ0ZZb0E#gid=0

Also, as you guys can see from the data, stack emulation is still required for 54% of my site's traffic.

While I'd like to see users upgrading to the latest browsers as much as any developer, let's be realistic: WinXP is not going away any time soon (Microsoft dropping support for it isn't going to make people like my dad go out and buy a new computer).  Google Analytics is shows that 80% of my users are on Windows and 21% of those are still on Windows XP: that is a very big number!

There are many other browsers available on Windows XP, and you should tell your dad that by continuing using an unsupported browser, his computer is at risk.

See also http://www.troyhunt.com/2013/01/the-impending-crisis-that-is-windows-xp.html

[Jens]

There are many other browsers available on Windows XP, and you should tell your dad that by continuing using an unsupported browser, his computer is at risk.

See also http://www.troyhunt.com/2013/01/the-impending-crisis-that-is-windows-xp.html

Hehe, I like the IE7 tax idea mentioned on that site :) 

-- J.