> Could it be changed to "Hit Enter" but only if the web browser doesn't
> close with a valid exit value.

There's no way of knowing if or when the web browser closed. The
webbrowser module spawns a background shell command, and never hears
what happens to the command.

Besides which, the common case is that the user already has their
browser open. I don't know how Galeon does it, but it's probably similar
to how Firefox works: the webbrowser module starts up a new Firefox
process, which tells the main Firefox process to open a URL in a new
tab. The new process then exits, possibly before the page is even
loaded.  So even if we did know when the browser process exited, that
information would be useless in the common case.

Right now after you grant permission, you see a web page that tells you
"you should go back to the application window in which you started the
process and inform it that you have done your part of the process." This
is pretty generic, but it has to be, because it has to work for every
conceivable client. Although now I see that it uses "process" in two
different senses, which should be changed. Anyway, we could allow the
client to specify some custom instructions here when it's setting up the
token. For the get_token_and_login case, "go back and hit enter" would
be better, though I suspect everyone would overlook it.

> Okay, so they why don't you grab STDOUT as well. I don't see why any
> text from the webbrowser should get to the user when using the console
> based utility. It's never going to be very readable.

I agree with you, but 1) that's not within my control, and 2) it should
be doing that already. According to the source of the webbrowser module,
both STDOUT and STDERR are redirected to /dev/null. That's why I'm
interested in how Galeon is actually being started by the webbrowser
module.

-- 
apport-collect should suppress STDERR
https://bugs.launchpad.net/bugs/337240
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.

-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to