398280 - kdice is not working anymore

Status: RESOLVED FIXED

(Core :: General, defect)

Description

[u286998]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007100205 Minefield/3.0a9pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007100205 Minefield/3.0a9pre

The page says that the sever is unavailable, although it is.
Additionally the buttons and links cannot be clicked upon.
the problem is probably JavaScript/AJAX related.

regression range between 2007-07-08 03:00 and 2007-07-09 05:00
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-07-08+03&maxdate=2007-07-09+05&cvsroot=%2Fcvsroot

Could be caused by Bug 382947 since that caused Bug 397234 (" unable to load page www.one.lt ") which is similar to this one and has the same regression range.

working:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a7pre) Gecko/2007070804 Minefield/3.0a7pre
not working:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a7pre) Gecko/2007070904 Minefield/3.0a7pre

From the error console:
Error: i has no properties
Source File: file:///C:/Dokumente%20und%20Einstellungen/Pyr0/Desktop/Downloads/firefox/modules/XPCOMUtils.jsm
Line: 98
Error: i has no properties
Source File: file:///C:/Dokumente%20und%20Einstellungen/Pyr0/Desktop/Downloads/firefox/modules/XPCOMUtils.jsm
Line: 98
Error: i has no properties
Source File: file:///C:/Dokumente%20und%20Einstellungen/Pyr0/Desktop/Downloads/firefox/modules/XPCOMUtils.jsm
Line: 98
Failed to load XPCOM component: C:\Dokumente und Einstellungen\Pyr0\Desktop\Downloads\firefox\components\nsContentDispatchChooser.js
Failed to load XPCOM component: C:\Dokumente und Einstellungen\Pyr0\Desktop\Downloads\firefox\components\nsHandlerService.js
Failed to load XPCOM component: C:\Dokumente und Einstellungen\Pyr0\Desktop\Downloads\firefox\components\nsPlacesTransactionsService.js


Reproducible: Always

Steps to Reproduce:
1. go to http://kdice.com/

Actual Results:  
buttons and links are not clickable, instead of the game a warning message shows up telling you that the server is unavailable
additionally there are some errors in the error console

Comment 1

[Martijn Wargers (dead)]

Yeah, that site also uses the Google Web Toolkit, so it seems to me that this is likely a problem that started occuring with the fix for bug 382947.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Has anyone contacted Google to figure out what the issue is?

Comment 3

[Marius Strumyla]

I found this in their issue tracker:
content-type can be "utf-8" as well as "UTF-8"
http://code.google.com/p/google-web-toolkit/issues/detail?id=1707

Comment 4

[Boris Zbarsky [:bzbarsky]]

Uh...  We sent "UTF-8" as far as I can tell....

Comment 5

[Marius Strumyla]

I did some digging around the GWT. I was running DynaTable sample from the toolkit. It uses RPC call (asynchronous request) to get server data. Some GWT versions throw an exception with current trunk. In all cases exception stack is the same, only the line numbers differ.

          | GWT 1.1.10 | 1.2.11  | 1.2.22  | 1.3.3   | 1.4.60 
----------+------------+---------+---------+---------+---------
 20070708 |     OK     |   OK    |   OK    |   OK    |   OK
 build    |            |         |         |         |
----------+------------+---------+---------+---------+---------
 20070709 |     EXC    |   EXC   |   OK    |   OK    |   EXC
 build    |            |         |         |         |

javax.servlet.ServletException: Content-Type must be 'text/plain' with 'charset=utf-8' (or unspecified charset)
	at com.google.gwt.user.server.rpc.RemoteServiceServlet.readPayloadAsUtf8(RemoteServiceServlet.java:552)
	at com.google.gwt.user.server.rpc.RemoteServiceServlet.doPost(RemoteServiceServlet.java:141)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
	at com.google.gwt.dev.shell.GWTShellServlet.service(GWTShellServlet.java:216)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214)
	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)

GWT builds used: 1.1.10, 1.2.11, 1.2.22, 1.3.3, 1.4.60

Minefield trunk builds used:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a7pre) Gecko/2007070904 Minefield/3.0a7pre
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a7pre) Gecko/2007070804 Minefield/3.0a7pre

Comment 6

[Boris Zbarsky [:bzbarsky]]

Marius, would you mind doing one of the failing tests while logging the HTTP traffic Gecko sends and receives using the directions at http://www.mozilla.org/projects/netlib/http/http-debugging.html ?  I'd like to see exactly what we're sending.  If you can log both a working and non-working build, that would be even better; then we can see exactly what the difference is and decide what to do with it.

Comment 7

[Marius Strumyla]

Attachment: GOOD log file using 20070708

Comment 8

[Marius Strumyla]

Attachment: BAD log file using 20070709

Comment 9

[Marius Strumyla]

I believe the problem happens when posting to /com.google.gwt.sample.dynatable.DynaTable/calendar. Contenty-Types are different.

Excerpt from GOOD log file (trunk build 20070708)
0[7c5770]:   Content-Type: text/plain; charset=utf-8;charset=UTF-8

Excerpt from BAD log file (trunk build 20070709)
0[7c5948]:   Content-Type: text/plain;charset=UTF-8

For comparison, ff2.0.0.7 is giving me this:
0[2347e8]:   Content-Type: text/plain; charset=utf-8

Comment 10

[Boris Zbarsky [:bzbarsky]]

Uh.... yeah.  That would definitely be a server bug, imo.  But the bug report in comment 3 seems to be backwards (as in, the server _is_ accepting "utf-8", but we send "UTF-8").

We might also want to restore the space after the ' ', but that really shouldn't be affecting things...

I guess if this hasn't been fixed on the Google side by the time we're close to shipping 1.9 we should lowercase the charset we send or something....

Comment 11

[Damon Sicore (:damons)]

OK.  Blocking on this.  

Comment 12

[Boris Zbarsky [:bzbarsky]]

Patch for bug 397234 fixed this.