Bug #83598
closed
Output of extbase debugger should go after doctype declaration
Added by Mordamir about 6 years ago.
Updated about 4 years ago.
Description
Currently the output of all extbase debug html goes to the start of the page, even before the doctype declaration. The output should go somewhere after doctype declaration.
A missing doctype declaration causes some strange behaviours. For instance, $(window).height() in jquery does result in document height and not in window height.
Files
hey mordamir.
thanks for the report.
Actually the debugger prints at the point (it does a simple PHP "echo") where it is called. This makes a lot of sense for debugging, especially when somebody debugs XHR/AJAX requests where there is no simple HTML. Detecting a proper HTML structure for debugging purposes wouldn't be feasible as well... So that's the reason it works as is right now.
Same problem here.
<f:debug> leads to the following code and potential CSS bugs with my pages in Quirks mode:
<style type='text/css'>
...
Debugger Styles
...
</style>
<div class="extbase-debugger extbase-debugger-floating">
...
Debugger Code
...
</div>
<!DOCTYPE html>
<html lang="de">
<head>
<meta charset="utf-8">
...
If i use <f:debug inline="1"> instead, I get the debugger at the expected position.
But then I get CSS problems within the debug output (arrays are inline, see screenshot from the official TYPO3 8 Introduction Package), making it hard to read the output, especially for arrays.
This might be another issue entirely, but neither debug option works well.
- Status changed from New to Rejected
- Priority changed from Should have to -- undefined --
To be honest, to me this debugger has the least priority of all tickets. Because:
- You don't use the debugger in production
- You use the debugger only temporarily
- The debugger doesn't need to be pixel perfect
- There are alternatives (at least in the php context)
That said, it's very unlikely I will put my hands on this ever.
But if someone comes up with a great idea to solve this, I will review the patch.
Until then, I will mark this ticket rejected.
Please don't be mad at me, we simply have a lot of more important tickets like real bugs that cost money.
I understand, no worries.
If I find the time I might look if the inline debugger issues can be fixed with CSS. Seems like the easiest solution to this problem...
Its not about the debugger being pixel perfect. Its about some javascript properties change behaviour if there is no doctype declaration. It can cause bugs of this type:
Hey, we have this problem on our website with browser xy, can you fix this? And then you try to figure out why its not working, staring at the values from the debugger stating all values are correct. Ok, all is correct and you switch off debugging and the error is back.
Now i know that if i need to debug strange issues i have to switch off the debuging output because some javascript properties change based on doctype. I know that the way it works now doesnt cause trouble in 99%. But that 1 % can cost you lots of hours trying figure out why the hell it is working if you debug it.
One way to solve this, could be to show up such debug data inside the adminpanel (if present), instead of just dumping it somewhere at the start of the html document. -> that's a small possible feature I would like to make in the future.
But you can't solve this in general for every use case. (See the reasoning of bennimack above)
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by 
Updated by 
Updated by 
Updated by 