[Django] #24960: {{ block.super }} hides UnicodeEncodeErrors
Django
------------------------------+--------------------------------------------
Reporter: srkunze | Owner: nobody
Type: Bug | Status: new
Component: Template | Version: master
system |
Severity: Normal | Keywords: block.super UnicodeEncodeError
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 1
------------------------------+--------------------------------------------
When using {{ block.super }}, it behaves like a normal variable which
leads to the following issue:
As soon as the block.super raises a UnicodeEncodeError, {{ block.super }}
evaluates to an empty string.
When using {{ block.super }} in cascading base templates, this frequently
leads to blank pages which are hard to debug.
--
Ticket URL: <https://code.djangoproject.com/ticket/24960>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
-------------------------------------+-------------------------------------
Reporter: srkunze | Owner: nobody
Type: Bug | Status: new
Severity: Normal | Resolution:
Keywords: block.super | Triage Stage:
UnicodeDecodeError | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 1
Changes (by srkunze):
* needs_better_patch: => 0
* needs_tests: => 0
* keywords: block.super UnicodeEncodeError => block.super
UnicodeDecodeError
* needs_docs: => 0
Old description:
> When using {{ block.super }}, it behaves like a normal variable which
> leads to the following issue:
>
> As soon as the block.super raises a UnicodeEncodeError, {{ block.super }}
> evaluates to an empty string.
>
> When using {{ block.super }} in cascading base templates, this frequently
> leads to blank pages which are hard to debug.
New description:
When using {{ block.super }}, it behaves like a normal variable which
leads to the following issue:
As soon as the block.super raises a UnicodeDecodeError, {{ block.super }}
evaluates to an empty string.
When using {{ block.super }} in cascading base templates, this frequently
leads to blank pages which are hard to debug.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/24960#comment:1>
Django
-------------------------------------+-------------------------------------
Reporter: srkunze | Owner: nobody
Type: Bug | Status: new
Severity: Normal | Resolution:
pages | Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 1
Changes (by srkunze):
* keywords: block.super UnicodeDecodeError => block.super blank pages
Old description:
> When using {{ block.super }}, it behaves like a normal variable which
> leads to the following issue:
>
> As soon as the block.super raises a UnicodeDecodeError, {{ block.super }}
> evaluates to an empty string.
>
> When using {{ block.super }} in cascading base templates, this frequently
> leads to blank pages which are hard to debug.
New description:
When using {{ block.super }}, it behaves like a normal variable which
leads to the following issue:
As soon as the block.super raises (e.g.) a UnicodeDecodeError, {{
block.super }} evaluates to an empty string.
When using {{ block.super }} in cascading base templates, this frequently
leads to blank pages which are hard to debug.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/24960#comment:2>
Django
-------------------------------------+-------------------------------------
Type: Bug | Status: closed
Component: Template system | Version: master
Severity: Normal | Resolution:
Keywords: block.super blank | Triage Stage:
pages | Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 1
Changes (by timgraham):
* status: new => closed
* resolution: => worksforme
Comment:
I couldn't reproduce this. We'll need more details such as a sample
project that reproduces the error. I got a yellow "debug page" when
`DEBUG=True` and a 500 error page when `DEBUG=False`. Thanks.
--
Ticket URL: <https://code.djangoproject.com/ticket/24960#comment:3>
Django
-------------------------------------+-------------------------------------
Type: Bug | Status: new
Severity: Normal | Resolution:
pages | Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 1
Changes (by srkunze):
* status: closed => new
* resolution: worksforme =>
Comment:
We created a minimal working example:
https://gist.github.com/srkunze/ee9d5e7b20bd543343e4
t1.html, t2.html << base templates
t3.html << example page using failing tag
t4.html << example page using failing variable
test_tag.py << example tag
test_output.py << test output rendering t3.html and t4.html
As you can see, t3.html and t4.html yields different results, although the
only difference is the usage of tags vs. variables.
The reason for this is the {{ block.super }} variable that filters out
failing tags.
--
Ticket URL: <https://code.djangoproject.com/ticket/24960#comment:4>
Django
-------------------------------------+-------------------------------------
Type: Bug | Status: new
Severity: Normal | Resolution:
Keywords: block.super blank | Triage Stage:
pages | Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 1
Comment (by timgraham):
Thanks for the example code, however, when I put those
`render_to_string()` calls into views like this:
{{{
def t3(request):
return render_to_string('t3.html')
def t4(request):
return render_to_string('t4.html', {'error': Error})
}}}
I get a yellow debug page in both cases. What behavior do you see? Do you
have `DEBUG=True`? Are you testing with master or some older version of
Django?
--
Ticket URL: <https://code.djangoproject.com/ticket/24960#comment:5>
Django
-------------------------------------+-------------------------------------
Type: Bug | Status: new
Severity: Normal | Resolution:
Keywords: block.super blank | Triage Stage:
pages | Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 1
Comment (by srkunze):
Are you sure that render_to_string(...) works as intended here? Should a
view not return a HttpResponse?
We used Django 1.6. We upgraded to Django 1.8 and it seems as if the error
is returned properly now.
We looked into the corresponding Django source code and found that Django
catches more errors as before and re-raises them. That approach seems a
bit error especially when using custom exceptions.
Don't you think that a check whether a context variable is callabed/has
attribute/has dictionary key should be handled not by trail and error but
by a check-before-do?
--
Ticket URL: <https://code.djangoproject.com/ticket/24960#comment:6>
Django
-------------------------------------+-------------------------------------
Type: Bug | Status: new
Severity: Normal | Resolution:
Keywords: block.super blank | Triage Stage:
pages | Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 1
Comment (by timgraham):
Yes, my usage of `render_to_string()` isn't proper, but it seemed enough
to test the code you provided.
I'm not following what you are saying now. Django 1.8 fixes the original
issue but there's another issue there? Please clarify what behavior you
are seeing and what the expected behavior is.
--
Ticket URL: <https://code.djangoproject.com/ticket/24960#comment:7>
Django
-------------------------------------+-------------------------------------
Type: Bug | Status: new
Severity: Normal | Resolution:
Keywords: block.super blank | Triage Stage:
pages | Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 1
Comment (by srkunze):
In Django 1.6, render_to_string does not work. Maybe, in Django 1.8 this
is also another convenience layer.
Well, not sure if Django 1.8 fixes the original issue. Infact, when
programming, we simply do not know which errors might occur. So, just
because Django re-raises TypeErrors now, does not necessarily mean that we
cover all cases (all types of errors).
As soon as somebody raises another exception that is not covered, we are
going to see a blank page again. So, our suggestion was: why not check if
the given context variable might work in the first place?
Right now, all Django versions just call the variables, do the attribute,
do the list access etc. So, we mix up both cases:
1. wrong access or
2. internal error when evaluating
cf.
https://github.com/django/django/blob/1.8.2/django/template/base.py#L804
We actually do not want an ever-growing list of Errors (TypeError,
AttributeError, KeyError, ValueError, IndexError -- as you can see in
base.py) but a clean long-lasting solution.
For instance, Python provides the function 'has_attr' which can be used to
check whether an object has a certain attribute or not. The same goes for
list access and function calls.
--
Ticket URL: <https://code.djangoproject.com/ticket/24960#comment:8>
Django
-------------------------------------+-------------------------------------
Type: Bug | Status: new
Severity: Normal | Resolution:
Keywords: block.super blank | Triage Stage:
pages | Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 1
Comment (by bmispelon):
For reference, I bisected the fix down to
28a571348bca9c5a3c137e495e7d3c9349a5bd56 which was a fix for #20745.
--
Ticket URL: <https://code.djangoproject.com/ticket/24960#comment:9>
Django
-------------------------------------+-------------------------------------
Type: Bug | Status: new
Severity: Normal | Resolution:
Keywords: block.super blank | Triage Stage:
pages | Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 1
Comment (by timgraham):
I still haven't managed to reproduce the "blank page" issue. Could you
given an example?
--
Ticket URL: <https://code.djangoproject.com/ticket/24960#comment:10>
Django
-------------------------------------+-------------------------------------
Type: Bug | Status: new
Severity: Normal | Resolution:
Keywords: block.super blank | Triage Stage:
pages | Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 1
Comment (by srkunze):
Thanks @bmispelon. TypeError was just a quick example. See comment:8, we
actually do not appreciate the trial-and-error approach that will lead to
an ever-growing except list.
--
Ticket URL: <https://code.djangoproject.com/ticket/24960#comment:11>
Django
-------------------------------------+-------------------------------------
Type: Bug | Status: new
Severity: Normal | Resolution:
Keywords: block.super blank | Triage Stage:
pages | Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 1
Comment (by srkunze):
@timgraham We see if we can produce an example for 1.8.
--
Ticket URL: <https://code.djangoproject.com/ticket/24960#comment:12>
Django
-------------------------------------+-------------------------------------
Type: Bug | Status: closed
Component: Template system | Version: master
Keywords: block.super blank | Triage Stage:
pages | Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 1
Changes (by srkunze):
* status: new => closed
* resolution: => fixed
Comment:
We further investigated the issue. We found that with an upgrade to 1.8,
we might resolve the issue of empty {{ block.super }}.
However, we might consider opening another issue for the inconsistencies
of variable resolution. We still would prefer a check-if-possible approach
instead of try-and-fail.
--
Ticket URL: <https://code.djangoproject.com/ticket/24960#comment:13>