To reproduce: 1. Open Writer/Web (e.g. via File > New > HTML Document) 2. Save the document (this is necessary because otherwise Writer/Web will not show you a source view of your file): File > Save As (etc.) 3. Switch to the source view: View > HTML Source Now, open the View menu again. Observe that "Print Layout" and "Web Layout" are grayed out i.e. unavailable. This is, despite the fact that the three items Print Layout/Web Layout/HTML Source should act as alternatives. (Which is implied by the UI, given the radio-button like circle in front of the item. And that they act as alternatives is also logical.) Now, to switch out of HTML Source view, you have to click View > HTML Source again. You are not able to use either of the logical items Print Layout or Web Layout. (I hope that makes a bit of sense.)
Confirmed on Windows 10 Pro 64-bit with Version: 5.2.0.3 (x64) Build ID: 7dbd85f5a18cfeaf6801c594fc43a5edadc2df0c CPU Threads: 8; OS Version: Windows 6.19; UI Render: GL; Locale: en-US (en_US) The mode toggles seem a little muddled. Unable to move back to Normal or Web layout without first toggling out of HTML Source view. So, it can be in HTML View--or not. And only if not, then either Normal (i.e. print preview) or Web view. Beleive intent is when toggled into the HTML view--the Normal and Web view widgets were not visible--instead of just greyed out. Not sure if that can be improved. @UX-Advise?
I would also expect that HTML Source is an option when I load such a document. But it is there only with Stefan's test sequence. Is this really an UX thing? It smells like a bug, or an inconsistency at the code.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Definitely a bug since the "HTML source" toggle button on the toolbar does the trick. Version: 6.0.4.2 Build ID: 6.0.4-2 CPU threads: 8; OS: Linux 4.17; UI render: default; VCL: gtk3; Locale: en-US (en_US.UTF-8); Calc: group
Dear Stefan Knorr (astron), To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
*** Bug 133204 has been marked as a duplicate of this bug. ***
*** Bug 145264 has been marked as a duplicate of this bug. ***
Will move my thoughts to the duplicate if oldest is best; I did search first but that's 2016. The longevity of this issue is noted.
(In reply to skyhook from comment #8) > Will move my thoughts to the duplicate if oldest is best; I did search first > but that's 2016. The longevity of this issue is noted. That was confusing. Requests are so similar I thought I was looking at my 2021 report. <a href="https://bugs.documentfoundation.org/show_bug.cgi?id=145264">145264</a> has been marked resolved. Back to the issue, I'll summarize by voting that this HTML format feature shouldn't exist, duplicating menu and tool bar or not: Pro: - once inside an HTML text file, togging text to WYSIWYG is handy Cons: - badly implemented menu control was my main reason for stepping in here - little gain from ten lines of boilerplate - forcing user new file awkward - little gain from HTML file extension if not editable by Writer - help file literally incorrect on re-open detail - long history of users confusing this issue Anybody editing HTML would save a text version of their source as their platform would likely have a different application associated with an HTML extension, also, a browser open to view and refresh edits as the proof in the pudding. I might still like the idea of toggling views, but its utility is so minimal I don't feel it justifies the confusion. If doubling down, the goal should be to have any existing HTML file toggle to text on demand, for editing.
(In reply to skyhook from comment #9) > ... > Anybody editing HTML would save a text version of their source as their > platform would likely have a different application associated with an HTML > extension, also, a browser open to view and refresh edits as the proof in > the pudding. I might still like the idea of toggling views, but its utility > is so minimal I don't feel it justifies the confusion. If doubling down, the > goal should be to have any existing HTML file toggle to text on demand, for > editing. Well in reality, the entire Writer/Web module is broken. It was implemented for HTML 4.0 transitional and provides no support for external CSS2 or CSS3. The developer consensus for bug 95861 is to strip out the entire Writer/Web module; and this issue with the HTML view "modes" just goes away. Essentially we don't want to work in HTML/XHTML directly--just on VCL canvas as needed by filter import to ODF. Another facet of that is though the XSLT based import and export filters do a reasonable job with ODF formatting they are non-performant, so a major C++ based refactoring of HTML/XHTML/XML import and export filters has been suggested. For myself, I've moved to the dump Writer/Web module as unsupported with no chance for dev maintenance or needed feature implementation. It just needs to be dropped.
(In reply to V Stuart Foote from comment #10) > (In reply to skyhook from comment #9) > > ...It just needs to be dropped. Thanks for reaching out. My final word on this, then, as a user: "What do you use it for?" was asked in 2017. I fell into this because I wanted to proof formatting in my Thunderbird sig's. That was a bit of a surprise in itself, that I had to work with tags. I could trial-and-error with test messages, and didn't require Writer. After I stripped increasing amounts of cruft, I learned all I needed was simple inline formatting like their grey placeholder. I wish detailed formatting was easier in TB but if TB interprets HTML anyway, doesn't it follow to use that functionality for other elements like signatures? I tried but no joy, it's all or nothing WYSIWYG, which is why I'm relating TB to Writer. With Writer, I can save formatting as HTML and monitor it in a browser; faster, easier, and up to date, and I can copy the code something else like a sig. I'm ignorant of the machinations behind save-as formatting, but I'm guessing losing HTML/Web would have some connection to losing the entire format option. At the current level of complexity, I can see why people might hesitate to lose a nice shortcut. Writer might have a place but not as a step towards a full-blown HTML5 editor, that the majority concede is off target and not trivial. I would call the current state somewhere in the middle and failing there, and it could be simplified. After reading the 2015 and the deprecation link, HTML/Web just feels like a pit trap that nobody is willing to fill in even though the war is over. I didn't see any significant pressure not to. Good luck.
(In reply to V Stuart Foote from comment #10) > Well in reality, the entire Writer/Web module is broken... > The developer consensus for bug 95861 is to strip out the entire Writer/Web > module; and this issue with the HTML view "modes" just goes away. So resolve this one as WF? Or ideally block loading/saving HTML documents (I disagree with bug 95861 and would just remove all of this).
Patch submitted making this item a checkbox.
Heiko Tietze committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/dc54d2477c6ad23e9132caf65849239bb9eab4fd Resolves tdf#101179 - Correct menu entry for View > HTML Source It will be available in 7.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
This bug has created problems on my site – far from it. In fact, we regularly use press releases as a way to generate earned media coverage for our clients, across all kinds of industries. href='https://kingnewswire.com/ is still a legitimate way to help tell company stories, educate potential clients and customers, and secure earned media coverage.