Closed Bug 251695 Opened 20 years ago Closed 19 years ago

Firefox displays XHTML <br /> tags as <br> in view selection source when served as text/html

Categories

(Toolkit :: View Source, defect)

Product:
Toolkit
Component:
View Source
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: dan.taylor, Assigned: bugs)

References

(
URL
)

Details

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040614 Firefox/0.8 This only occurs with server generated pages such as PHP, if I put exactly the same code into a static html page the view source shows the correct <br /> tag. I've used the WDG site validator and the page validates as XHTML1.1 and I can't replicate the problem in another browser. Reproducible: Always Steps to Reproduce: 1. View page 2. View source 3. Expected Results: Should show <br /> tags in source
Sorry, forgot to mention, its only on views selection source, not on the main view source
5 Content-type: text/html that's html, not xhtml
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → INVALID
The code output is xhtml <br />, when using selection view source the <br /> tags become <br>, when using the main view source <br /> remains as <br />.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
view selection source serializes the DOM, while the normal view source shows the file as it was received. it is impossible for view selection source to always show the file contents unmodified, as javascript can modify the dom, and thus the selection may not be present in the original document. That said, it looks like selection source does not even close tags if the page was sent as xhtml... testcase: data:application/xml,<html xmlns="http://www.w3.org/1999/xhtml">a<br/>n</html>
Hmmm ... isn't Firefox using the fix of bug 190947 (a disclaimer in the titlebar). Reporter : View selection source never represents the actual source (that would be impossible to implement if you consider DOM modifications) -- it is a serialization of the DOM. That means that on an HTML page (not XML) it should be dropping the '/' from <br />. And because of the mime-type, your page is HTML, not XHTML.
As far as I can see the change of MIME type makes no difference to the view source selection, and at the moment as far as I understand it use of this content-type rather than text/html is suggested rather than compulsory until xhtml2.0 (also the xml definition at the start of the file) cheers
OS: Windows XP → All
Hardware: PC → All
> As far as I can see the change of MIME type makes no difference Yep. That's a bug (due to the fact that we're using innerHTML on some nodes that hang out in the middle of nowhere, I think....) As for the rest, using text/html for XHTML is and always has been a hack. You _will_ get different behavior doing that than if you use an XHTML MIME type.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Adding a dependence to bug 155723. If that bug is fixed, this one will just go away.
Depends on: 155723
Summary: Firefox displays XHTML <br /> tags as <br> in view source → Firefox displays XHTML <br /> tags as <br> in view selection source
Special Characters, such as ä (&auml;) or " (&quot;), are not being converted in "View Selection Source", even if the original source code has them converted.
That has nothing to do with this bug and is covered by its own (invalid) bug.
Bug 233386 covers that problem, too, and has been considered invalid. So what's the difference to this bug here, as I can't see how the method of creation (dynamic vs. static) can have an impact?
My mistake its nothing to do with Dynamic or static content. You're right about the Bug 233386, it is the same problem and I take onboard Boris Zbarsky's points on that bug, but i think a better outcome can be achieved by examining the doctype and assuming the code is consistant with the that.
Product: Browser → Seamonkey
Assignee: doronr → bugs
Component: ViewSource → View Source
Product: Mozilla Application Suite → Firefox
QA Contact: view-source
Version: Trunk → unspecified
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050831 Firefox/1.0+ ID:2005083106 Nothing much to add, just that this behavior persists in the above nightly (whether it's actually a bug, I shall leave for a better person to decide).
If bug 155723 hasn't fixed the bug for you, it would simply mean that the server is not serving the page as XHTML. Try the testcase that I just put on the URL field above, and you will see that it works.
URL: data:application/xml,<html xmlns="htt...
The fact that this bug needs multiple resolutions shows it has outlived its usefulness: for the original XHTML-as-HTML URL as a bug, it's invalid; for XHTML-as-XHTML it's fixed by bug 155723, as an RFE to have view selection source (or, "DOM Source of Selection" as the window title puts it, trying to make it clear what it is) fake the output based on mime-type it's a certain wontfix. Since the bug has been about text/html almost the entire time, that seems like the best of the three.
Status: NEW → RESOLVED
Closed: 20 years ago → 19 years ago
Resolution: --- → WONTFIX
Summary: Firefox displays XHTML <br /> tags as <br> in view selection source → Firefox displays XHTML <br /> tags as <br> in view selection source when served as text/html
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.