User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.57 Safari/537.36 Steps to reproduce: GeckoEventListener can be responsible(GeckoEventResponder) or unresponsible. For responsible case, the listener will call getResponse() and may block the current thread(PromptService). It was used by PromptService before. But now i find that PromptService always use async method, the remaining code for sync case are not complete, for example, PromptService.getResponse() may be called recursively, but there is not solution to tell which message matches the result(In Prompt.jsm, a guid is used to solve the problem). So i think the java code for sync case is useless, and can be removed. Some classes like CallbackWrapper and GeckoApp are GeckoEventResponder's subclasses, but i think there are other solutions to avoid using GeckoEventResponder. For example, we can use something like guid to match the result, just like Prompt.jsm do. I haven't read those two classes carefully, what i say may be wrong. So I think we can remove GeckoEventResponder, and always use async method. Actual results: useless code in PromptService.java for sync case, and GeckoEventResponder is useless Expected results: no GeckoEventResponder

The prompt service "async" stuff you can happily remove. I left it in while we were transitioning away from it, but I don't want it around anymore. Prompt:ShowTop can die I think as well (I wanted that to be a parameter anyway, and not a new message). I think you should probably file individual bugs for the other GeckoEventResponder's and handle them on a case by case basis (but yeah, it would be nice to get rid of them all). Some, like the ones in GeckoApp for WebApps:Install and Intent:GetHandlers will be messy to remove, but that's a good sign the js code needs cleanup anyway.

These were all killed in bug 946344.