Just to finish this off in case anyone else has the same problem - this was fixed in r11031.
https://code.google.com/p/google-web-toolkit/source/detail?r=11031 On Wed, Jun 6, 2012 at 6:52 PM, Chris Price <[email protected]> wrote: > I've just tried to take the demo for a spin but I had a few problems > trying to convince the dev_mode_on code that super dev mode was > enabled. Hopefully I'm missing something but from a quick look over > the code I think something might be unavailable in the public version. > > dev_mode_on contains the following conditional when showing/hiding the > compile bookmarklet - > > var mod = modules_on_page[module_name]; > > var dev_mode_key = '__gwtDevModeHook:' + module_name; > var dev_mode_on = mod['superdevmode'] || > window.sessionStorage[dev_mode_key]; > > if (!dev_mode_on && !mod.canRedirect) { > return 'This module doesn\'t have Super Dev Mode enabled'; > } > > In my case it keeps falling into the "This module doesn't have SDM > enabled" block and no SDM for me! However, if I force one of the > conditions to skip the block everything works nicely for that compile > and subsequent compiles. I'm assuming that the sessionStorage is > responsible for latching the behaviour, so I looked into what sets > window.__gwt_activeModules[module_name]['superdevmode'] and > window.__gwt_activeModules[module_name].canRedirect. > > The only place I can find that sets > window.__gwt_activeModules[module_name]['superdevmode'] is a custom > version (although the original doesn't seem to be in the source tree) > of computeScriptBase.js which isn't used by the standard > CrossSiteIframeLinker. A comment in Recompiler suggests that it is > used by Google's server-side linker. > > window.__gwt_activeModules[module_name].canRedirect seems only to be > set by the DevModeRedirectHook.js which is included by > CrossSiteIframeLinker when devModeRedirectEnabled is true. However, > Recompiler checks for the existence of this property (throwing if it > doesn't exist) before forcing it to false. > > My current workaround is to prepend the following onto my dev mode on > bookmarklet - > > window.__gwt_activeModules.hello.superdevmode = true; > > Is this a genuine problem or am I going about this all wrong? > > Chris > > On Tue, Jun 5, 2012 at 9:02 PM, <[email protected]> wrote: >> Ray, you can see the diffs by looking at internal code review. I updated >> a bunch of javadoc, tweaked Recompiler to deal with running with a >> different linker, and changed the regexps in WebServer to be slightly >> tighter and a bit more readable. But sure, basically the same. >> >> >> >> >> http://gwt-code-reviews.appspot.com/1727804/diff/1/dev/codeserver/BUILD >> File dev/codeserver/BUILD (right): >> >> http://gwt-code-reviews.appspot.com/1727804/diff/1/dev/codeserver/BUILD#newcode1 >> dev/codeserver/BUILD:1: # Copyright 2012 Google Inc. All rights >> reserved. >> On 2012/06/05 01:05:21, cromwellian wrote: >>> >>> Do we really want the BUILD file in the public repo? >> >> >> I was using an out-of-date version of rietveld that didn't ignore these >> files. Fixed. >> >> >> http://gwt-code-reviews.appspot.com/1727804/diff/1/dev/codeserver/java/com/google/gwt/dev/codeserver/AppSpace.java >> File dev/codeserver/java/com/google/gwt/dev/codeserver/AppSpace.java >> (right): >> >> http://gwt-code-reviews.appspot.com/1727804/diff/1/dev/codeserver/java/com/google/gwt/dev/codeserver/AppSpace.java#newcode2 >> dev/codeserver/java/com/google/gwt/dev/codeserver/AppSpace.java:2: * >> Copyright 2011 Google Inc. >> On 2012/06/05 10:52:58, tbroyer wrote: >>> >>> 2012 ? >> >> >> Well, I started on some of these files last year, so I'm going to leave >> it. >> >> >> http://gwt-code-reviews.appspot.com/1727804/diff/1/dev/codeserver/java/com/google/gwt/dev/codeserver/ModuleState.java >> File dev/codeserver/java/com/google/gwt/dev/codeserver/ModuleState.java >> (right): >> >> http://gwt-code-reviews.appspot.com/1727804/diff/1/dev/codeserver/java/com/google/gwt/dev/codeserver/ModuleState.java#newcode49 >> dev/codeserver/java/com/google/gwt/dev/codeserver/ModuleState.java:49: >> defaultProps.put("user.agent", "safari"); >> On 2012/06/05 10:52:58, tbroyer wrote: >>> >>> This is just a "default" for the very first compilation, right? >>> (but hard-coding things that way will prevent detecting the "right" >> >> permutation >>> >>> later on, no?) >> >> >> Yes, this is just for the first compile and the output isn't intended to >> be run. Normally when you are running a separate server, the binding >> properties will be computed by the nocache.js script of the >> non-superdevmode version of the GWT app, and then they're saved in >> session storage, so we always compile the same permutation. >> >> However, I recently added support for running html files directly out of >> the Super Dev Mode code server (for an all-static GWT app where a >> separate server isn't needed). In that case, the initial compile *is* >> used, which is the wrong permutation if you're not using Safari or >> Chrome. And on the second compile, it will build all permutations, which >> is another bug. >> >> I'll be fixing this later. I'd like to see if there's a way to terminate >> the initial compile early and not output a permutation. It's a useful >> sanity check but shouldn't take too long. >> >> >> http://gwt-code-reviews.appspot.com/1727804/diff/1/dev/codeserver/java/com/google/gwt/dev/codeserver/Options.java >> File dev/codeserver/java/com/google/gwt/dev/codeserver/Options.java >> (right): >> >> http://gwt-code-reviews.appspot.com/1727804/diff/1/dev/codeserver/java/com/google/gwt/dev/codeserver/Options.java#newcode134 >> dev/codeserver/java/com/google/gwt/dev/codeserver/Options.java:134: >> private class SourceFlag extends ArgHandler { >> On 2012/06/05 10:52:58, tbroyer wrote: >>> >>> Why not use ArgHandlerDir? >> >> >> This variant actually checks that the directory exists. (Probably >> ArgHandlerDir should be fixed, but I didn't want to get into that.) >> >> >> http://gwt-code-reviews.appspot.com/1727804/diff/1/dev/codeserver/java/com/google/gwt/dev/codeserver/Options.java#newcode148 >> dev/codeserver/java/com/google/gwt/dev/codeserver/Options.java:148: >> return "The root of a directory tree containing GWT source code to >> compile."; >> On 2012/06/05 16:15:35, cromwellian wrote: >>> >>> On 2012/06/05 10:52:58, tbroyer wrote: >>> > Does this mean SuperDevMode no longer loads sources from the >> >> classpath? >> >>> It picks up from the classpath, but this directory shadows the >> >> classpath. The >>> >>> reason is, at least for Google, we always produce source-jars in our >> >> internal >>> >>> build system, and you can't 'edit' them. That is, when we launch >> >> superdevmode, >>> >>> it has the source, but it's been compiled and put into jars on the CP. >> >> This >>> >>> directory allows us to specify another location to look at, in >> >> addition to the >>> >>> classpath (which is the fallback) >> >> >>> For external users, it may not be needed, although I could see if >> >> superdevmode >>> >>> is launched from a Maven build you might run into the same issue. >> >> >> >> Tweaked the help text a bit. >> >> >> http://gwt-code-reviews.appspot.com/1727804/diff/1/dev/codeserver/java/com/google/gwt/dev/codeserver/WebServer.java >> File dev/codeserver/java/com/google/gwt/dev/codeserver/WebServer.java >> (right): >> >> http://gwt-code-reviews.appspot.com/1727804/diff/1/dev/codeserver/java/com/google/gwt/dev/codeserver/WebServer.java#newcode164 >> dev/codeserver/java/com/google/gwt/dev/codeserver/WebServer.java:164: // >> This is a GET because a bookmarklet can call it from a different origin >> (JSONP). >> On 2012/06/05 10:52:58, tbroyer wrote: >>> >>> We should probably use CORS and XMLHttpRequest with a POST request, >> >> instead of >>> >>> JSON-P. The bookmarklet could handle XDomainRequest for IE8/9 and even >> >> possibly >>> >>> create an HTML form if we want to support IE6/7. >> >> >>> White-listing origins from command-line arguments would also add some >> >> security. >> >> Yeah, CORS is better and I'm not too concerned about old browsers. Users >> would have to maintain the whitelist, though. If we want to wildcard >> hostnames (e.g. everything under corp.google.com), I think that requires >> a preflight request? >> >> >> http://gwt-code-reviews.appspot.com/1727804/diff/1/dev/codeserver/java/com/google/gwt/dev/codeserver/WebServer.java#newcode456 >> dev/codeserver/java/com/google/gwt/dev/codeserver/WebServer.java:456: >> private static String escapeHtmlCharacters(String line) { >> On 2012/06/05 10:52:58, tbroyer wrote: >>> >>> Couldn't we use SafeHtml.fromString() here? >> >> >> Currently, gwt-codeserver.jar only depends on gwt-dev.jar (and its >> dependencies) and I'd rather not add the dependency until it enables a >> more important feature. >> >> >> http://gwt-code-reviews.appspot.com/1727804/ >> >> -- >> http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
