Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

debugging javascript within browsers is hard when the browser show the full response on a single line #675

Closed
GoogleCodeExporter opened this issue Mar 25, 2015 · 5 comments
Closed

debugging javascript within browsers is hard when the browser show the full response on a single line #675

GoogleCodeExporter opened this issue Mar 25, 2015 · 5 comments
Labels
auto-migrated Priority-Medium Type-Defect Version-Seaside3.0

Comments

@GoogleCodeExporter
Copy link 

Seaside's response is viewed by browsers as a string without line-breaks.
Normally this isn't a problem as the browser "pretty-prints" the output when 
inspecting the html.
However when debugging javascript, either inline or within a file-library the 
script debugger (I'm currently using Safari) shows the output as a single line 
- which makes it impossible to interpret any javascript generated errors 
("syntax error: line 1"!!) or to set meaningful breakpoints.

I've discovered that calling #withInternetLineEndings on the file-library 
string results in browsers interpreting the  line-endings as expected.

Locally when I'm debugging I've created a class derived from WAHtmlDocument, 
which overrides #nextPutAll: 
WAHtmlDocumentWithInternetLineEndings>>#nextPutAll: aString
    super nextPutAll: aString withInternetLineEndings

and I modify WAFileLibrary>>#handle: modifying the WAResponse>>#document: to: 
document: ((self documentForFile: fileName) withInternetLineEndings)

Is there a better solution?

Original issue reported on code.google.com by Nick.A...@gmail.com on 7 Aug 2011 at 10:31
@GoogleCodeExporter
Copy link
Author 

So the problem is that the JavaScript sources have whatever the Smalltalk 
newline is (likely cr on Pharo) instead of cr lf?

Original comment by philippe...@gmail.com on 7 Aug 2011 at 11:36

  • Added labels: ****
  • Removed labels: ****

@GoogleCodeExporter
Copy link
Author 

yes that's the issue

Original comment by Nick.A...@gmail.com on 7 Aug 2011 at 12:23

  • Added labels: ****
  • Removed labels: ****

@GoogleCodeExporter
Copy link
Author 

Now I've discovered the '{ }' button in Chrome and Safari debuggers this is no 
longer an issue for me.

Perhaps the issue can be closed?

Original comment by Nick.A...@gmail.com on 7 Aug 2011 at 12:34

  • Added labels: ****
  • Removed labels: ****

@GoogleCodeExporter
Copy link
Author 

I agree, no need to worry about formatting in the response when tools are there 
to do it on the front end. I would close the issue as well.

Original comment by bpo...@gmail.com on 7 Aug 2011 at 7:02

  • Added labels: ****
  • Removed labels: ****

@GoogleCodeExporter
Copy link
Author 

Very well then.

Original comment by philippe...@gmail.com on 8 Aug 2011 at 5:25

  • Changed state: WontFix
  • Added labels: ****
  • Removed labels: ****

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
auto-migrated Priority-Medium Type-Defect Version-Seaside3.0
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@GoogleCodeExporter