Closed Bug 18453 Opened 25 years ago Closed 25 years ago

Non-alphanumeric characters not highlighted in view-source

Categories

(Core :: DOM: Selection, defect, P3)

Product:
Core
Component:
DOM: Selection
Type:
defect

Tracking

()

Status:
VERIFIED DUPLICATE of bug 12460

People

(Reporter: elig, Assigned: mjudge)

Details

* TITLE/SUMMARY
Non-alphanumeric characters not highlighted in view-source

* STEPS TO REPRODUCE
0) Launch Apprunner
1) View any web page; e.g. www.mozilla.org
2) From the View menu, select "Page Source"
3) Select the displayed page source

* RESULT
 - What happened

Only alphanumeric characters (and quotes, along with the content that they
contain) are selected.

 - What was expected

All text to be selected.

* REGRESSION

 - Occurs On
        Mac OS Apprunner (1999110913)
        Linux Apprunner (1999110913)
        Win32 Apprunner (1999110808)


 - Doesn't Occur On
        Communicator 4.7 (Mac OS)


* CONFIGURATIONS TESTED

- [Mac] Beige Power Mac G3 (266 MHz PowerPC 750), 96 MB RAM (VM on; 1 MB of VM
used), 1024x768 (Thousands of Colors), Mac OS 8.6

- [Win32] Vectra VL (233 MHz P2), 96 MB RAM, 800x600 (True Color), NT 4.0 SP5.

- [Linux] Vectra VL (266 MHz P2), 96 MB RAM. Red Hat Linux 6.0 (GNOME).
Target Milestone: M13
setting this to m13, I think this may be considered a blocker
Additional Observations:
1. The "</" and ">" characters of the last end tag at the end of the last line
   selected are highlighted, but the alpha characters of that end tag are not
   highlighted! (As soon as the selection moves on to the next line,
   the alpha characters are highlighted and the "</" and ">" characters
   are unhighlighted).
2. Clicking once to the right of the end of a line does not clear the selection.
3. Clicking anywhere inside a line and outside the selection clears the
   selection, but random "<", "/" and ">" characters will still be highlighted.
4. The behaviour described in 3. is even more visible if the selection is
   shrunk within the same click-drag.
Hope there's a clue in there somewhere.

Tested with:
1999-11-10-16-M11 on Windows NT 4.0sp3
1999-11-11-08-M12 on Windows NT 4.0sp3 (exact same results)
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
dup 12460 this is generated content problem

*** This bug has been marked as a duplicate of 12460 ***
Since I cannot prove on a black box level that this is a duplicate, I'm going to
hold off until 12460 is fixed before accepting the duplicate resolution.
elig: Actually, technically speaking you can tell that viewsource uses generated
content by looking at the end of html.css.
Doh. I give up. 

Ian, if you feel so inclined, could you possibly share what line of html.css 
makes it clear that non-alphanumeric characters in View Source are generated 
content?

Or I can just rubber-stamp it as verified. I'm sure you know what you're talking 
about. thanks!

Don't give up, Eli! :-)

Near the end, the html.css file has:

   viewsource|start:before {content: "<"; color: black;} 
   viewsource|start:after {content: ">"; color: black;} 
   viewsource|end:before {content: "</"; color: black;} 
   viewsource|end:after {content: ">"; color: black;} 

This means that in the "viewsource" namespace, which is what we use displaying
documents in viewsource mode, the "start" and "end" elements, which are what we
generate for <start> and </end> tags, will have "<" before them, and ">" after
them ("</" and ">" respectively for the end tags).

In case this above makes no sense, it might be useful for you to know that when
we display viewsource, we are actually rendering an XML representation of the
document's DOM, not any internally generated thing. Try changing the html.css
file so that it says something like:

   viewsource|start:before {content: " BEFORE THE START TAG! "; color: black;} 

...and then viewsource again. Quite amusing... ;-)

Heh. Cute. Thanks much for the thorough explanation, Mr. Hickson. Verified/
Duplicate.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.