Closed Bug 164906 Opened 22 years ago Closed 15 years ago

view selection source shows generated code instead of actual source

Categories

(Toolkit :: View Source, enhancement)

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

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: bugzilla, Unassigned)

References

Details

User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.1) Gecko/20020826 Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.1) Gecko/20020826 If you select test on a page, then "view selection source", the source code displayed is not the actual source code. Rather, it is generated source code based on the parse tree. This is documented at <URL:http://bugzilla.mozilla.org/show_bug.cgi?id=60426#C25> as being a feature, but the UI isn't clear on whether this functionality is. From reading Bugzilla, I think this is a feature, so the bug is that the UI is extremely vague on this point. See also: View Selection Source replaces non-breaking spaces <URL:http://bugzilla.mozilla.org/show_bug.cgi?id=155635> Reproducible: Always Steps to Reproduce: 1.Select Source 2.Right click 3.View Selected Source Actual Results: You see the generated source Expected Results: Expected to see the actual source.
To rbs. This is certainly a ui issue only; there is no way to show the "original" source for a selection that is entirely dom-generated.
Assignee: harishd → rbs
Status: UNCONFIRMED → NEW
Component: Parser → XP Apps
Ever confirmed: true
What about caching? If the web browser is not set to refresh on every webpage then it would use old caching when using "View Source".
> This is certainly a ui issue only I have no other suggestion for a name. There was already a dilemma about picking a more appropriate name in bug 122524 comment 46 and ff. The current name is the one on the UI specs: http://mozilla.org/projects/ui/communicator/framework/contextmenus/index.html#Anchor-52467 Re: comment #2 Viewing the generated source fills a few gaps that are not covered by the classical view-source. For example, it allows debugging/capturing live HTML generated via JavaScript, or it can help QA to quickly extract simplified testcases from complex web pages. It can also help to capture output transformed by XSLT (indeed, if you try view-source on a page with XSLT, you get the original XML source with its initial XSLT stylesheet -- whereas Ctrl-A & View Selection Source shows the final transformed document and you can then re-use/copy-paste bits and pieces elsewhere). -> Marking WONTFIX. Cc:ing a few UI folks if they can find a better name.
Severity: trivial → enhancement
Status: NEW → RESOLVED
Closed: 22 years ago
Component: XP Apps → XP Apps: GUI Features
OS: Windows 98 → All
Hardware: PC → All
Resolution: --- → WONTFIX
*** Bug 188122 has been marked as a duplicate of this bug. ***
*** Bug 182863 has been marked as a duplicate of this bug. ***
*** Bug 190926 has been marked as a duplicate of this bug. ***
Boris, as per your comment http://bugzilla.mozilla.org/show_bug.cgi?id=164906#c1 that DOM cannot show the original source, I am fine with that, but couldn't DOM at least remember which parts it "fixed" and mark them in red as per my suggestion 2) in http://bugzilla.mozilla.org/show_bug.cgi?id=190926 ? Just for some additional user-friendliness for those who use Mozilla as rendering tool when creating html by other means ...
> but couldn't DOM at least remember which parts it "fixed" Not without imposing unacceptable performance and speed overhead on rendering of web pages. We're a browser first, source viewer second, unfortunately.
Boris, understood, added RFE http://bugzilla.mozilla.org/show_bug.cgi?id=191067 as an idea that might overcome this.
*** Bug 191419 has been marked as a duplicate of this bug. ***
-> see bug 190947, head over to that bug if you have a suggestion about a simple and intuitive way to remind users that the source comes from the DOM.
*** Bug 199106 has been marked as a duplicate of this bug. ***
*** Bug 199106 has been marked as a duplicate of this bug. ***
*** Bug 205615 has been marked as a duplicate of this bug. ***
*** Bug 206571 has been marked as a duplicate of this bug. ***
*** Bug 210790 has been marked as a duplicate of this bug. ***
*** Bug 236465 has been marked as a duplicate of this bug. ***
*** Bug 236505 has been marked as a duplicate of this bug. ***
*** Bug 245851 has been marked as a duplicate of this bug. ***
*** Bug 248905 has been marked as a duplicate of this bug. ***
*** Bug 263171 has been marked as a duplicate of this bug. ***
Product: Core → Mozilla Application Suite
*** Bug 291139 has been marked as a duplicate of this bug. ***
*** Bug 316968 has been marked as a duplicate of this bug. ***
*** Bug 340663 has been marked as a duplicate of this bug. ***
*** Bug 353779 has been marked as a duplicate of this bug. ***
I just stumbled across this bug while trying to debug a weird rendering problem in an RSS aggregator page. The correct HTML source as-sent-by-the-browser can be viewed with the main "view source" link from the menu, whereas "view selection source" mucked around with a whole bunch of it. I really don't mind that it's showing me rendered source, but IMO it's really *got* to let the user know that the source being shown is NOT the source which is coming from the server. Now, I know that I have to just use "View Source" and do some searching to get what I want, but I never even thought about doing that previously, because it was a pretty large HTML page and the "view selection source" feature was so handy. Now I find out that for debugging rendering problems on webpages, "view selection source" is completely useless. I don't see what the problem with calling it "View Rendered Selection Source" or somesuch would be. I agree that it might be a bit confusing, but it'll be far *less* confusing for a user who's trying to figure out why what should be a long string of </li> entities got turned into two </div>s instead. I shouldn't have to bust out a packet sniffer just to figure out where the HTML is getting changed.
"Rendered source" is an oxymoron. :-) Anyway, making it clear is bug 190947.
Ah, well, right you are. And I do see the title of "DOM Source of Selection" now that it's been pointed out, but honestly, how often do people look at the title of the window of the HTML source you're looking at? What's the harm in having the menu option say "View Selection DOM" or whatever, then? My point is that the menu item that a user clicks on to do an action does *not* do what it says it will. That's poor UI regardless of what the title of the resulting window is. Is a better place for this discussion over in the other bug, then?
Component: XP Apps: GUI Features → UI Design
The steady flow of duplicate reports for this issue and reports like bug 233386, bug 407199 show that the hint "DOM Source" in the window title is to small to be recognized. This hint resulted from bug 190947. A better message that the window shows "generated" or "interpreted" content is needed. Window title should read "DOM Source interpreted from selection" or similar.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Assignee: rbs → nobody
Component: UI Design → View Source
Product: SeaMonkey → Toolkit
QA Contact: moied → view.source
(In reply to comment #32) How about "View Selection Source" -> "View Selection as Source" or "View Selection as(or in) HTML"? This bug is for behaviour of functionality named "View Selection Source", and definition/design of functionality named "View Selection Source" will not be changed as WONTFIX states, and it's worked/working and probably will continue to work as designed. As complaint of "behaviour is different from my thought!" looks repeatedly posted to B.M.O, I also think something is better to be improved. Hb [:Hb], could you open separate bug(Enhancement, I think), please. Closing again as WONTFIX, as closed on 2002-08-27.
Status: REOPENED → RESOLVED
Closed: 22 years ago → 15 years ago
Resolution: --- → WONTFIX
Bug 728992 was talking purely about the action of "copy", not mentioned elsewhere above.

https://alternatifjavaslot88.com/

situs slot online 24jam aman dan terpercaya
gaming slot online paling gacor dan viral
slot online deposit 24jam paling fast respon

You need to log in before you can comment on or make changes to this bug.