57722 - view-source leaves out whitespace at end of document

Status: RESOLVED DUPLICATE of bug 85505

(Core :: DOM: HTML Parser, enhancement)

Description

[Jesse Ruderman]

If an html page contains only whitespace (spaces, tabs, and Windows newlines), 
view source won't display anything.  I should be able to select text to see how 
much whitespace there is.

occurs at:
javascript:" "
javascript:" \n   \n "

doesn't occur at:
javascript:" \n 3 \n "    because it contains a non-whitespace character

And then there's the empty-line issue.. afaict the only way to tell if Mozilla 
thinks there's a newline at the end of a short document is to scrunch the view-
source window.  That's somewhat more counter-intuitive than selecting to 
determine the presense of spaces :)

Comment 1

[timeless]

Maybe the style sheet should be changed so that text background is a different 
color than what it is now.  I think w3.org uses all sorts of interesting 
styles, many of which would help.

Comment 2

[timeless]

Attachment: A method of hinting at whitespace. [using css]

Comment 3

[timeless]

Basically, clicking anywhere w/ the text will cause the entire text region to 
be semi yellowed.  I know that css can add borders to objects, but it migt be 
useful if we could -moz- style lines of <pre> so that you could have a border 
around the whitespace (instead of or in addition to the background coloring).

Hixie: thoughts?

Comment 4

[Hixie (not reading bugmail)]

Agreed that you should be able to select the whitespace, for pure correctness
reasons, but why on earth would you want to check anyway?

This can be fixed when we go back to XML view source and the view source window
is styled using CSS again. Feel free to assign to me if you would want me to
mess with the styles in the way suggested by timeless once we are there again.

Comment 5

[Jesse Ruderman]

>why on earth would you want to check anyway?

I want to know why bug 57717 doesn't affect data: urls.

Comment 6

[harishd]

Based on Ian's comment I'm reassigning the bug to him.

Comment 7

[Hixie (not reading bugmail)]

This won't be fixed by me unless we switch back to an XML-based view source.
We won't switch back to XML-based view source until genererated content is 
selectable. I can't find either of those bugs, but this is dependent on those.

Comment 8

[Jan Carpenter]

Not mine, handing off to sairuh

Comment 9

[Boris Zbarsky [:bzbarsky]]

OK.  We are still doing HTML view source.... but we are now using a stylesheet. 
Hixie, could you take a look into this again?

Word of warning -- regular #text nodes in the source do not currently get their
own <span> elements, but those could be reinstated (at a very slight perf hit).

The generate content bug is bug 12460

Comment 10

[Hixie (not reading bugmail)]

I can't do anything here without a UI spec, since I don't know what would be 
best. Handing off to UID. Send it back when a spec is ready and I'll triage it
if it is beyond my meager skills. :-)

Comment 11

[Jesse Ruderman]

Also happens at javascript:"3\n<b> \n ".  Everything after the <b> is cut off.

Comment 12

[Matthew T (active 1999-2002)]

Erm ... What do you want here? Some sort of toggle which will hide/show 
whitespace characters as little dots and pilcrows and stuff?

The more I see these sort of bugs, the more I think View Source should just be 
handled by the helper app which the user has chosen for text/plain.

Comment 13

[Jesse Ruderman]

I don't care if Mozilla shows the whitespace, I just want to be able to select 
it like I can select normal text or whitespace that isn't at the end of the 
document.  (Btw, if I do Ctrl+A and copy from view source, I do get the 
whitespace, but I can't see the selected whitespace in the view-source window)

Comment 14

[Andreas M. "Clarence" Schneider]

*** This bug has been marked as a duplicate of 57724 ***

Comment 15

[Christopher Hoess (gone)]

Reopening 57724 dependencies for independent resolution.

Comment 16

[Jonas Jørgensen]

.

Comment 17

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: testcase

This looks like it's a layout bug. The testcase has a <pre> element with a lot
of newlines in it (but nothing under those). View-source is generating the
newlines, but they're simply not being rendered.

Comment 18

[Blake Kaplan (:mrbkap) (inactive)]

View-source is doing all it can here. The inability to select lines with only a
newline in them is covered by bug 85505. So basically, the moment that bug is
fixed, we can mark this bug as fixed.

Comment 19

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 20

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 21

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 22

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 23

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 24

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 25

[Boris Zbarsky [:bzbarsky]]

Look.  If you don't want this bug in Seamonkey, fine.  But then don't move it back in there, dammit!

Comment 26

[Henri Sivonen (:hsivonen)]

Per comment 18 marking as duplicate of bug 85505.