Output of extbase debugger should go after doctype declaration
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.
Updated by Benni Mack almost 2 years ago
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.
Updated by Florian Seirer over 1 year ago
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.
Updated by Alexander Schnitzler over 1 year ago
- 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.
Updated by Mordamir over 1 year ago
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.
Updated by Christian Eßl over 1 year ago
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)