Created attachment 37772 [details] Response Body unformatted - HTML Source Formatted As of JMeter 5.4.1 on a Mac, when viewing the response body for a request in the View Results Tree, there is no longer a code-formatted monospace "view source" display when "Text" or "HTML Source Formatted" are selected as the filter. In previous versions of JMeter, one would see a "view source" look and feel, where line numbers were displayed and the response body was rendered in a monospace font and "preformatted" . In 5.4.1 this is no longer the case -- there are no line numbers and the response body text is not monospace or "preformatted" when either "Text" or "HTML Source Formatted" is selected.
Created attachment 37773 [details] Response Body unformatted - Text
Have you tried an older version? Which one? I don't see any changes in the source, that would lead to such a change. Maybe you mixed it with CSS or other views in the View Results Tree panel?
(In reply to Felix Schumacher from comment #2) > Have you tried an older version? Which one? I don't see any changes in the > source, that would lead to such a change. Maybe you mixed it with CSS or > other views in the View Results Tree panel? Hi Felix! :) Yes, I've reverted back to 5.2.1 which doesn't have the problem. In terms of the view, please check out the attached screenshots which show both "Text" and "HTML Source Formatted" views in View Results Tree. Note that neither view shows line numbers nor monospace font code formatting, whereas in JMeter 5.2.1 both views do show line numbers and code formatting. Thanks!
Hi Brian, I build 5.2.1 from source and on linux there is no line numbering or monospaced font on the response body. The response header panel has those features, though. Can you post an image of the old version showing the response body panel?
Created attachment 37777 [details] v5.2.1 Response Body Text - Formatted
Created attachment 37778 [details] v5.2.1 Response Body HTML Source - Formatted
Felix - That's odd. On Mac I am definitely seeing line numbers and monospace formatting for both Text and HTML Source Formatted selections under the Response Body tabs of View Results Tree. I've attached 2 new screenshots from v5.2.1. There's also this bug that I filed for 5.2.1 which shows the same perspective, though I'm pointing out that the text displayed in "Darcula" theme is dark text on a dark background: https://bz.apache.org/bugzilla/show_bug.cgi?id=64224 Thanks!
Strange. Is this a Mac thing (I somehow doubt it)? Do you have any third party libraries installed? Did you use the downloaded version from our home page, or did you install the version via brew or something like that?
I don't believe I have any third party libraries installed other than JMeter Plugin Manager. Certainly nothing that should affect View Results Tree. Since I'm on a Mac I did install JMeter 5.2.1 via Homebrew. Is there a specific JAR file you need me to inspect?
I suspect that you again have some variant of a jsyntaxpane in the lib folder like the brew install from https://bz.apache.org/bugzilla/show_bug.cgi?id=63360 My lib folder has the following jars: $ ls lib/ aareadme.txt geronimo-jms_1.1_spec-1.1.1.jar junit-4.12.jar accessors-smart-1.2.jar groovy-all-2.4.16.jar log4j-1.2-api-2.12.1.jar api hamcrest-2.1.jar log4j-api-2.12.1.jar apiguardian-api-1.1.0.jar hamcrest-core-2.1.jar log4j-core-2.12.1.jar asm-7.1.jar hamcrest-date-2.0.4.jar log4j-slf4j-impl-2.12.1.jar bsf-2.4.0.jar httpasyncclient-4.1.4.jar mail-1.5.0-b01.jar bsh-2.0b6.jar httpclient-4.5.10.jar miglayout-core-5.2.jar bshclient.jar httpcore-4.4.12.jar miglayout-swing-5.2.jar caffeine-2.8.0.jar httpcore-nio-4.4.12.jar mongo-java-driver-2.11.3.jar checker-qual-2.10.0.jar httpmime-4.5.10.jar neo4j-java-driver-1.7.5.jar commons-codec-1.13.jar jackson-annotations-2.9.10.jar opt commons-collections-3.2.2.jar jackson-core-2.9.10.jar oro-2.0.8.jar commons-dbcp2-2.5.0.jar jackson-databind-2.9.10.jar ph-commons-9.3.7.jar commons-io-2.6.jar javax.activation-1.2.0.jar ph-css-6.2.0.jar commons-jexl-2.1.1.jar jcharts-0.7.5.jar rhino-1.7.11.jar commons-jexl3-3.1.jar jcl-over-slf4j-1.7.28.jar rsyntaxtextarea-3.0.4.jar commons-lang3-3.9.jar jmespath-core-0.3.0.jar Saxon-HE-9.9.1-5.jar commons-logging-1.2.jar jmespath-jackson-0.3.0.jar serializer-2.7.2.jar commons-math3-3.6.1.jar jodd-core-5.0.13.jar slf4j-api-1.7.28.jar commons-net-3.6.jar jodd-lagarto-5.0.13.jar tika-core-1.22.jar commons-pool2-2.7.0.jar jodd-log-5.0.13.jar tika-parsers-1.22.jar commons-text-1.8.jar jodd-props-5.0.13.jar xalan-2.7.2.jar darcula-e208efb96f70e4be9dc362fbb46f6e181ef501dd.jar jorphan.jar xercesImpl-2.12.0.jar dec-0.1.2.jar json-path-2.4.0.jar xml-apis-1.4.01.jar dnsjava-2.1.9.jar json-smart-2.3.jar xmlgraphics-commons-2.3.jar error_prone_annotations-2.3.3.jar jsoup-1.12.1.jar xmlpull-1.1.3.1.jar ext jtidy-r938.jar xpp3_min-1.1.4c.jar freemarker-2.3.29.jar junit xstream-1.4.11.jar
Nice catch, Felix! Indeed in my Homebrew install of 5.2.1, I DO see jsyntaxpane-1.0.0.jar, whereas it is missing in my Homebrew install of 5.4.1. To test, I temporarily moved jsyntaxpane-1.0.0.jar out of my lib folder and opened a JMeter test. Now when I look at the same Response Body results for Text and HTML Source Formatted I no longer see line numbers or a monospace font. Note that I also am not getting any kind of missing class error with jsyntaxpane-1.0.0.jar no longer in lib. So to your point about how jsyntaxpane got installed, I have no idea. I guess the question I have is why wouldn't we want jsyntaxpane to be installed since it gives better response body display, or even more importantly why does "Text" and "HTML Source Formatted" give the same display of unstyled text. Even better, wouldn't it be ideal to use the same formatter as the Response Headers panel (which seems to have code syntax highlighting and line numbers) for the HTML Source Formatted selection in the Response Body panel?
Created attachment 37779 [details] Response headers formatter output
I change the severity of this bug report to enhancement and try to answer your questions below. The jsyntaxpane has led to at least one bug report in the past (see the linked bug report above), which is, why I don't favour adding thoughtlessly. And it seems, that it has problems with the dark mode which would have to be fixed, too. We can't use (easily) the JSyntaxTextArea for the document part, as that is using a different object type, which is not supported by JSyntaxTextArea. The difference between the formatted and non-formatted view might be hard to see. The formatted view will try to format the HTML source code by adding spaces here and there. If your source code was formatted nicely before, there will (hopefully) be no difference. If someone finds a nice way to add a more stylish display for the document view, rest assured that patches are always welcome :)