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.