Code

Opened 6 years ago

Closed 6 years ago

Last modified 5 years ago

#7000 closed (wontfix)

Provide option to automatically open development server URL with webbrowser (std lib)

Reported by: jezdez Owned by: jezdez
Component: Core (Other) Version: master
Severity: Keywords: browser command runserver
Cc: flori@… Triage Stage: Design decision needed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

I think it would be a very useful addition in the daily development work to have an option that opens the URL of the develeopment server in the default system browser.

For example restview makes use of Python's webbrowser module that is used in the attached patch.

Attachments (1)

open_browser.1.diff (4.1 KB) - added by jezdez 6 years ago.
patch including docs

Download all attachments as: .zip

Change History (12)

Changed 6 years ago by jezdez

patch including docs

comment:1 follow-up: Changed 6 years ago by programmerq

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Design decision needed

This looks useful. The only thing I would suggest is that the code for opening a browser should be executed once when the command is invoked initially, so the autoreload can still be enabled. If I were to use this feature, I'd probably run the command once, ctrl+c, remove the --browser option, and start it again. In my opinion, it almost defeats the purpose.

comment:2 Changed 6 years ago by telenieko

I'm not sure about that, mainly, as webbrower docs say, if it needs to use a text browser for some reason the server will lock.

comment:3 in reply to: ↑ 1 Changed 6 years ago by jezdez

Replying to programmerq:

Right, having autoreload would be useful, I'm going to change the patch to call webbrowser.open outside of the inner_run() loop.

Replying to telenieko:

Since "--browser" is off by default there is no way a developer on a text shell would accidentally use it. Though I agree that this should be documented by stating --browser is most useful in graphical environments. I think it saves serious time in daily work.

comment:4 Changed 6 years ago by jezdez

  • milestone set to post-1.0
  • Status changed from new to assigned

I'm setting this to post-1.0 since it's just not that important.

comment:5 Changed 6 years ago by Alex

Correct me if I'm wrong, but won't that fail on users who enter 0 or 0.0.0.0 as their ip(since it is a catchall)?

comment:6 Changed 6 years ago by Alex

And I stand corrected, it will indeed work.

comment:7 Changed 6 years ago by telenieko

RFC1700, around page 4, 0.0.0.0 *must* only be used as a source address (i.e.: bind to all interfaces) but not as destination.
It'd be better to translate 0.0.0.0 to "localhost" before opening the browser.

comment:8 Changed 6 years ago by flosch

  • Cc flori@… added

comment:9 Changed 6 years ago by jezdez

As a compromise I suggest adding that feature to the runserver_plus command of the django_extensions app. What do you think?

comment:10 Changed 6 years ago by jezdez

  • Resolution set to wontfix
  • Status changed from assigned to closed

Closing as wontfix after adding the option to the revision 113 of the django_extensions app.

comment:11 Changed 5 years ago by anonymous

  • milestone post-1.0 deleted

Milestone post-1.0 deleted

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.