Fixes #181 where the scrollbar would not show on any page other than the sqlalchemy_select.html template. The scroll classname is now properly named and applied throughout all panel templates as flDebugScroll. I've also added a 10px bottom padding to show the end of the inner panel (for aesthetics sake).

Recent updates to Flask and related components have included support for Python 3, and it would be great to be able to use Flask-DebugToolbar in projects running on Python 3. As it stands now, Flask-DebugToolbar must be disabled in such projects in order to run them without errors.

Are there plans to support Python 3 in the near future?

If you reorder DEBUG_TB_PANELS so ProfilerDebugPanel comes before RequestVarsDebugPanel, you'll get an obscure error: AttributeError: 'functools.partial' object has no attribute '__module__'

This is OK:

DEBUG_TB_PANELS = [
    'flask_debugtoolbar.panels.request_vars.RequestVarsDebugPanel',
    'flask_debugtoolbar.panels.profiler.ProfilerDebugPanel',
]

This is not:

DEBUG_TB_PANELS = [
    'flask_debugtoolbar.panels.profiler.ProfilerDebugPanel',
    'flask_debugtoolbar.panels.request_vars.RequestVarsDebugPanel',
]

I'm still gathering data, but it appears as though recent flask-debugtoolbar versions cause a memory leak. After I upgraded to Flask and Werkzeug 0.8 I also had to update flask-debugtoolbar from baecf852dda0f5b6c4700fb6deaeda4068b3a19c to current master (45ce65c058a580d80e2ac207689601edef5db24b), I've been noticing memory usage growing on every request made against the server.

I've disabled my custom panels and the ones from MongoEngine but left TimerDebugPanel, HeaderDebugPanel, RequestVarsDebugPanel, TemplateDebugPanel, LoggingPanel and ProfilerDebugPanel enabled.

Here is the output from heapy for a run with the debug panel disabled with DEBUG_TB_ENABLED=False. The first set is the total number of objects by type. The second set is the types of the objects that refer to the ones in the front. If you are familiar with heapy, the former is heap() and the latter is heap().byrcsL

Partition of a set of 202 objects. Total size = 40656 bytes.
 Index  Count   %     Size   % Cumulative  % Kind (class / dict of class)
     0     11   5     9224  23      9224  23 dict (no owner)
     1     16   8     8456  21     17680  43 types.FrameType
     2     59  29     5128  13     22808  56 str
     3     30  15     3728   9     26536  65 unicode
     4     16   8     1600   4     28136  69 list
     5      1   0     1048   3     29184  72 dict of flask.ctx.RequestContext
     6      1   0     1048   3     30232  74 dict of flask.wrappers.Request
     7      1   0     1048   3     31280  77 dict of flask.wrappers.Response
     8      1   0     1048   3     32328  80 dict of mimetools.Message
     9      1   0     1048   3     33376  82 dict of werkzeug.routing.MapAdapter
<35 more rows. Type e.g. '_.more' to view.>

Partition of a set of 202 objects. Total size = 40656 bytes.
 Index  Count   %     Size   % Cumulative  % Referrers by Kind (class / dict of class)
     0     22  11     7912  19      7912  19 types.FrameType
     1     67  33     7736  19     15648  38 dict (no owner)
     2      1   0     3352   8     19000  47 __builtin__.cell, dict of flask.wrappers.Request, dict
                                             of werkzeug.datastructures.EnvironHeaders,
                                             types.FrameType
     3     17   8     3136   8     22136  54 list
     4      6   3     1472   4     23608  58 dict of mimetools.Message
     5      2   1     1120   3     24728  61 dict of 0x7fca19073b90
     6      1   0     1048   3     25776  63 flask.ctx.RequestContext
     7      1   0     1048   3     26824  66 flask.wrappers.Request
     8      1   0     1048   3     27872  69 flask.wrappers.Response
     9      1   0     1048   3     28920  71 mimetools.Message
<41 more rows. Type e.g. '_.more' to view.>

A run with the debug toolbar enabled:

Partition of a set of 538 objects. Total size = 81920 bytes.
 Index  Count   %     Size   % Cumulative  % Kind (class / dict of class)
     0     35   7    20552  25     20552  25 dict (no owner)
     1    135  25    11128  14     31680  39 str
     2    122  23    10472  13     42152  51 tuple
     3     16   3     8208  10     50360  61 types.FrameType
     4     34   6     4064   5     54424  66 unicode
     5     31   6     4024   5     58448  71 list
     6     46   9     1104   1     59552  73 int
     7      1   0     1048   1     60600  74 dict of blinker._saferef.BoundMethodWeakref
     8      1   0     1048   1     61648  75 dict of flask.ctx.RequestContext
     9      1   0     1048   1     62696  77 dict of flask.wrappers.Request
<79 more rows. Type e.g. '_.more' to view.>

Partition of a set of 538 objects. Total size = 81920 bytes.
 Index  Count   %     Size   % Cumulative  % Referrers by Kind (class / dict of class)
     0    143  27    16712  20     16712  20 list
     1     30   6    12544  15     29256  36 types.FrameType
     2     83  15    10000  12     39256  48 dict (no owner)
     3    116  22     6592   8     45848  56 tuple
     4      1   0     3352   4     49200  60 __builtin__.cell, dict (no owner), dict of
                                             flask.wrappers.Request, dict of
                                             werkzeug.datastructures.EnvironHeaders, types.FrameType
     5      6   1     1472   2     50672  62 dict of mimetools.Message
     6      2   0     1120   1     51792  63 dict of 0x7f9d02073f00
     7      1   0     1048   1     52840  65 blinker._saferef.BoundMethodWeakref
     8      1   0     1048   1     53888  66 dict of
                                             flask_debugtoolbar.panels.headers.HeaderDebugPanel
     9      1   0     1048   1     54936  67 flask.ctx.RequestContext
<84 more rows. Type e.g. '_.more' to view.>

Hopefully you can see that the dict, str, and tuple usage is much larger with the debug toolbar, and that list objects seem to be holding a large number of references, with dict also in there. Is it possible that the toolbar is holding onto references that isn't being released?

I'm going to investigate a bit more and see if there is anything that stands out in the diffs between the two commits I referenced earlier, and to see if it seems to be an issue with a particular panel.

https://github.com/mgood/flask-debugtoolbar/blob/master/flask_debugtoolbar/init.py#L205

if you have a utf-8 character where the capital letter is represented in 1 byte, but the lower case character is represented in 2 bytes, then the location of the closing body tag fails.

İstanbulİstanbulİstanbul

The first character is problematic. A solution would be take in the closing tag string as a config argument and not do any lowering during string comparison.

This import is throwing a deprecation warning with Flask 0.11

flask_debugtoolbar/panels/sqlalchemy.py:2:    from flask.ext.sqlalchemy import get_debug_queries, SQLAlchemy

If you have an extension like Flask Compress compressing the contents of your responses with gzip before it's sent back to the user, flask debug toolbar will throw an error because it assumes the response is UTF-8 HTML.

Traceback (most recent call last):
  File "/usr/local/lib/python2.7/site-packages/flask/app.py", line 1836, in __call__
    return self.wsgi_app(environ, start_response)
  File "/usr/local/lib/python2.7/site-packages/flask/app.py", line 1820, in wsgi_app
    response = self.make_response(self.handle_exception(e))
  File "/usr/local/lib/python2.7/site-packages/flask_restful/__init__.py", line 270, in error_router
    return original_handler(e)
  File "/usr/local/lib/python2.7/site-packages/flask/app.py", line 1403, in handle_exception
    reraise(exc_type, exc_value, tb)
  File "/usr/local/lib/python2.7/site-packages/flask/app.py", line 1817, in wsgi_app
    response = self.full_dispatch_request()
  File "/usr/local/lib/python2.7/site-packages/flask/app.py", line 1479, in full_dispatch_request
    response = self.process_response(response)
  File "/usr/local/lib/python2.7/site-packages/flask/app.py", line 1691, in process_response
    response = handler(response)
  File "/usr/local/lib/python2.7/site-packages/flask_debugtoolbar/__init__.py", line 202, in process_response
    response_html = response.data.decode(response.charset)
  File "/usr/local/Cellar/python/2.7.10/Frameworks/Python.framework/Versions/2.7/lib/python2.7/encodings/utf_8.py", line 16, in decode
    return codecs.utf_8_decode(input, errors, True)
UnicodeDecodeError: 'utf8' codec can't decode byte 0x8b in position 1: invalid start byte

When logging sql statements with sqlalchemy panel the following exception is thrown:

Traceback (most recent call last): File "C:\Python27\lib\site-packages\flask\app.py", line 1518, in call return self.wsgi_app(environ, start_response) File "C:\Python27\lib\site-packages\flask\app.py", line 1506, in wsgi_app response = self.make_response(self.handle_exception(e)) File "C:\Python27\lib\site-packages\flask\app.py", line 1504, in wsgi_app response = self.full_dispatch_request() File "C:\Python27\lib\site-packages\flask\app.py", line 1266, in full_dispatch_request response = self.process_response(response) File "C:\Python27\lib\site-packages\flask\app.py", line 1414, in process_response response = handler(response) File "C:\Python27\lib\site-packages\flask_debugtoolbar__init__.py", line 171, in process_response toolbar_html = self.debug_toolbars[real_request].render_toolbar() File "C:\Python27\lib\site-packages\flask_debugtoolbar\toolbar.py", line 74, in render_toolbar return template.render(**context) File "C:\Python27\lib\site-packages\jinja2\environment.py", line 894, in render return self.environment.handle_exception(exc_info, True) File "C:\Python27\lib\site-packages\flask_debugtoolbar\templates\base.html", line 48, in top-level template code {{ panel.content()|safe }} File "C:\Python27\lib\site-packages\flask_debugtoolbar\panels\sqlalchemy.py", line 79, in content query.statement + _params).hexdigest() UnicodeDecodeError: 'ascii' codec can't decode byte 0xb2 in position 0: ordinal not in range(128)

As far as I understand, the panel concatenates application SECRET_KEY and query statement and params. My secret key is a byte string which contains some non-ascii characters like "'\xb2q\xf6\x8c\xcd\xd0\x023...". I had generated it with the following method which has been described in Flask quickstart docs:

import os os.urandom(24) '\xfd{H\xe5<\x95\xf9\xe3\x96.5\xd1\x01O<!\xd5\xa2\xa0\x9fR"\xa1\xa8'

http://flask.pocoo.org/docs/quickstart/

The toolbar's CSS file isn't injected into the template when using the HTML5 boilerplate <html> element:

<!doctype html>
<!--[if lt IE 7]> <html class="no-js ie6 oldie" lang="en"> <![endif]-->
<!--[if IE 7]>    <html class="no-js ie7 oldie" lang="en"> <![endif]-->
<!--[if IE 8]>    <html class="no-js ie8 oldie" lang="en"> <![endif]-->
<!--[if gt IE 8]><!--> <html class="no-js" lang="en"> <!--<![endif]-->

I would submit a pull request but I can't seem to find where this is being done.

I added the flask debug toolbar to my app. It looks working because it gave me the redirect warning like below:

_Redirect (302) Location: /app/bokeh

The Flask Debug Toolbar has intercepted a redirect to the above URL for debug viewing purposes. You can click the above link to continue with the redirect as normal. If you'd like to disable this feature, you can set the config variable DEBUG_TB_INTERCEPT_REDIRECTS to False._

But there is no FDT tool bar shown up after I got the response. I tried both Chrome and Firefox, same result. Do I need to do any configuration on the browser side to display the toolbar?

"flask.ext" (https://github.com/pallets/flask/issues/1135) has been deprecated a while ago. FdT keeps importing flask_sqlalchemy with flask.ext resulting in warning messages:

exthook.py:71: ExtDeprecationWarning: Importing flask.ext.sqlalchemy is deprecated, use flask_sqlalchemy instead

I have an issue with subdomain support. It seems that debug toolbar is always loading on the main domain but not the subdomains.

For example, if I have test.com, admin.test.com, and user.test.com. When I go to admin.test.com or user.test.com debug toolbar is loading all js, styles etc from test.com and if test.com is blocked it is not loading anything at all.

What will be good is that if I go to user.test.com it will load everything from it. If I go to admin.test.com it will load from it and when I go to test.com it will load from it.

I can work on pr for this just not sure what should be changed to support it and where?

It's probably time we dropped support for python 2: https://github.com/pallets-eco/flask-debugtoolbar/blob/e3c8ab0ca28d7ddfaaa731ef1e15649182255c6a/setup.cfg#L33

Given that Flask requires 3.7, I'd be fine with jumping straight to that... anyone who is on an older version of python can continue using an older version of Flask.

There's no immediate pressing need to jump to the latest python, but it makes future contributors lives easier because they don't have to worry about such a wide swathe of backwards compatibility.

First though we should push a final 2.x compatible release, that's tracked in https://github.com/pallets-eco/flask-debugtoolbar/issues/192... only once that's done should we do this.

Now that https://github.com/pallets-eco/flask-debugtoolbar/pull/186 has landed, we should push a release so folks can use it.

This will likely happen as part of #188 because we'll need to update the project metadata links anyway for PyPI.

@nickjj suggested we migrate from Travis to GitHub actions... We should definitely do that:

• [ ] Add new GitHub workflows
• [ ] Update the CI links in the readme to point at them instead of Travis: https://github.com/pallets-eco/flask-debugtoolbar/blob/master/README.rst
• [ ] Delete old travis workflows
• [x] I looked into deleting the travis org for https://travis-ci.org/github/flask-debugtoolbar (xref #188) but it looks like this isn't even possible... the page has a banner at the top about migrating to travis.ci and says builds stopped two years ago.

We're migrating the location of this repo from flask-debugtoolbar/flask-debugtoolbar to pallets-eco/flask-debugtoolbar to co-locate it alongside a number of other popular Flask-related extensions.

In order to complete this migration, we need to do a few things:

• [x] transfer the repository to the pallets-eco org
• [x] Make myself & @nickjj repo admins - this needs @davidism
• [x] Make @mattaw a repo collaborator - I think I can do this once @davidism adds him to the pallets-eco org
• [ ] Make @davidism and @ThiefMaster owners on https://pypi.org/project/Flask-DebugToolbar/ in case we ever need to publish an immediate security update or something more trusted users have access- I just sent them invites
• [ ] Update outdated links to mgood/flask-debugtoolbar or flask-debugtoolbar/flask-debugtoolbar to point to pallets-eco/flask-debugtoolbar instead... I currently see some in https://github.com/pallets-eco/flask-debugtoolbar/blob/master/docs/index.rst and https://github.com/pallets-eco/flask-debugtoolbar/blob/master/setup.cfg
• [ ] Cut a new release of flask-debugtoolbar and push to PyPI so that the project metadata on https://pypi.org/project/Flask-DebugToolbar/ points to the correct URLs.