Description: The title gives everything; When you are editing html to go out the valid options "standard" and "web" are not activated, the user must click again on the html-view other to go back to previous view. Steps to Reproduce: 1.activate html-view 2.try to go back to standard view even html modified is valid 3. Actual Results: Must click on the option html-view to inactivate it Expected Results: If html view can be leaved, the view options standard and web can be clicked Reproducible: Always User Profile Reset: No Additional Info: An imported ergonomic from elsewhere
I can't reproduce it in Versió: 6.1.3.2 ID de la construcció: 1:6.1.3~rc2-0ubuntu0.16.04.1 Fils de CPU: 4; SO: Linux 4.15; Renderitzador de la IU: per defecte; VCL: gtk3; Configuració local: ca-ES (ca_ES.UTF-8); Calc: group threaded To be certain the reported issue is not related to corruption in the user profile, could you please reset your Libreoffice profile ( https://wiki.documentfoundation.org/UserProfile ) and re-test? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the issue is still present
Hi, I could nor reproduce just now with my current version upgraded to 60.2.1 (problem found with 52.x) I will check on ancient version and try to understand. No corrupted profile. Nevertheless I will check what happens when there are bad error written in html (errors which generally crashed wysiwig) . Generally some not closed tags have no effect while code written is not changed but there are other bad cases which generally crashes html viewers (browsers). Such miswriting should lock the return to edit and show the error.
(In reply to Bernard TREMBLAY from comment #2) > Hi, > > I could nor reproduce just now with my current version upgraded to 60.2.1 > (problem found with 52.x) > I will check on ancient version and try to understand. > > No corrupted profile. > > Nevertheless I will check what happens when there are bad error written in > html (errors which generally crashed wysiwig) . > Generally some not closed tags have no effect while code written is not > changed but there are other bad cases which generally crashes html viewers > (browsers). Such miswriting should lock the return to edit and show the > error. Thanks for retesting with the latest version. Setting to RESOLVED WORKSFORME as the commit fixing this issue hasn't been identified.