Description: On pc Debian testing package 6.0.6, I got no personas. (idem with master sources updated today). Steps to Reproduce: 1. Open Writer 2. Menu Options/Personalization 3. Click "Own Theme" then "Select Theme" button => a new window appears titled "Select Firefox Theme" 4. Click any button of "Categories" and wait a bit until "Searching, please wait..." message disappears. Actual Results: No theme retrieved Expected Results: Should retrieve some themes Reproducible: Always User Profile Reset: Yes Additional Info:
Confirmed with https://bugs.documentfoundation.org/show_bug.cgi?id=114731#c22
Trying some debugging on gdb, I noticed several points: 1. when adding some traces, it seems block retrieved from urls doesn't contain "data-browsertheme" (see https://opengrok.libreoffice.org/xref/core/cui/source/options/personalization.cxx#577) 2. we expect """ for a quote but these same traces don't show any of them 3. textcolor attribute (see https://opengrok.libreoffice.org/xref/core/cui/source/options/personalization.cxx#590) may be null. "textcolor":null 4. urls have some kind of encoding, don't know if it was always the case: "previewURL":"https:\u002F\u002Faddons.cdn.mozilla.net\u002Fuser-media\u002Faddons\u002F420822\u002Fpreview_large.jpg?modified=8c8d0aab"
UX-team: I've posted a message this morning on dev mailing list (see http://document-foundation-mail-archive.969070.n3.nabble.com/About-Persona-lightweight-themes-td4244320.html) but think you may be interested in this one. Indeed, I wonder if this feature is really used. Just my opinion but I think there's enough work with icon themes to add some extra work by maintaining this feature.
Created attachment 143715 [details] bt with debug symbols bt showing where there's the pb with source URL.
needsUXEval needs CC ux-advice (will reply on the ML)
Just a guess, broken because of this: https://blog.mozilla.org/addons/2018/07/12/upcoming-changes-for-themes/ ?
(In reply to Buovjaga from comment #6) > Just a guess, broken because of this: > https://blog.mozilla.org/addons/2018/07/12/upcoming-changes-for-themes/ ? Good catch! It may indeed be related!
Bug 59611 UI: Give personas an own entry in Tools Menu gives an option for users to develop test and use their own personas without needing online Firefox. I documented my offline use in attachment 127480 [details]. I hope any changes to the Personas/themes support will not stop this function from working.
*** Bug 119239 has been marked as a duplicate of this bug. ***
I've just noticed this sentence on the blog: "The preview feature will be disabled starting today" Shouldn't we remove preview part and just keep install/uninstall dialog?
*** Bug 119278 has been marked as a duplicate of this bug. ***
Let's increase importance of this one considering it's a regression and it's indeed used (see dups).
*** Bug 119327 has been marked as a duplicate of this bug. ***
*** Bug 119654 has been marked as a duplicate of this bug. ***
I like this feature very well. It's something MSO hasn't and it's similar to Firefox browser which also many know. If it's possible in any way, please don't remove this unique office suite feature.
From the UX POV we have some options: a) remove this feature completely b) don't access images via network but ship a few and make the feature an extension c) revamp the code to adopt the new API Without any user data I cannot say how often personas are used. So a) is not a good solution. And c) sounds like a lot of work, similar to b) but we would gain full control over the persona configuration. Plus, this approach strengthens the extensions and allows the design team to make things fancy. My take is b).
(In reply to Heiko Tietze from comment #16) >... > c) revamp the code to adopt the new API Where can the new API be found?
(In reply to Julien Nabet from comment #17) > Where can the new API be found? needsDevAdvice?
(In reply to Heiko Tietze from comment #18) > (In reply to Julien Nabet from comment #17) > > Where can the new API be found? > > needsDevAdvice? Indeed because looking at the comments in https://blog.mozilla.org/addons/2018/07/12/upcoming-changes-for-themes/, nothing is indicated about a new API. IMHO, if Mozilla doesn't provide any API quickly (in some weeks and not some years), solution a) (remove the feature) should be considered seriously
(In reply to Julien Nabet from comment #19) > (In reply to Heiko Tietze from comment #18) > > (In reply to Julien Nabet from comment #17) > > > Where can the new API be found? > > > > needsDevAdvice? > > Indeed because looking at the comments in > https://blog.mozilla.org/addons/2018/07/12/upcoming-changes-for-themes/, > nothing is indicated about a new API. > > IMHO, if Mozilla doesn't provide any API quickly (in some weeks and not some > years), solution a) (remove the feature) should be considered seriously This older article https://blog.mozilla.org/addons/2018/03/08/theme-api-update/ says "Static themes, which only contain a manifest and image resources, will be supported on addons.mozilla.org (AMO) early this year. These will replace LightWeight Themes in a backward and forward compatible way." Static themes are explained here: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Themes/Theme_concepts#Static_themes It seems support for them has been fully implemented less than a month ago: https://github.com/mozilla/addons-frontend/projects/6 but maybe the Addons site is still not ready to accept them. Yet, I think we should remember the biggest issue: the previews are gone! Nothing I've read indicated they will be coming back. I think this is a strong point in favour of removing the feature completely.
(In reply to Buovjaga from comment #20) > Yet, I think we should remember the biggest issue: the previews are gone! > Nothing I've read indicated they will be coming back. I think this is a > strong point in favour of removing the feature completely. Just to make this crystal clear: https://github.com/mozilla/addons-frontend/issues/3056 "Since future web-ext based lightweight themes don't allow preview and install and uninstall is quick and easy I'd like to propose we remove the theme preview feature everywhere."
Michael: any thoughts about followings to give about this one? (see last comments)
Stephan's thoughts: https://lists.freedesktop.org/archives/libreoffice/2018-September/080894.html "In general, be careful when including new kinds of data content in extensions. That creates new interfaces between LO and extensions, and those interfaces need to be kept compatible, which is a maintenance burden."
ESC discussion: http://document-foundation-mail-archive.969070.n3.nabble.com/Libreoffice-qa-minutes-of-ESC-call-td4248098.html
What I have by taking a quick look: - There is no problem with the API part (The API we use is indeed deprecated but still functional, the API change of mozilla is something different (not related to our use case) AFAIK) - Seems like there has been some change on the design of the individual persona/theme pages on AMO (addons.mozilla.org) which causes our parser methods to fail I can quickly cook up a patch to make our Personas search feature operational again, but we better think about a way to improve this feature overall, and make it future-proof. Mozilla might make design changes anytime again which breaks things on our side. Random thoughts: - Select a small set of personas (maybe 10 or 20?), and ship them with LO - Include an index file for a larger set of Personas, which might be updated by a script time to time (maybe getting most-downloaded 100 (or 1000?) Personas), and perform the searches on this set of Personas.
For my part - I think shipping a small set of default personas with the product would be really useful. Microsoft ship (I think) three ;-) and make it easy to select one when you first start / upgrade. So while we shipped the feature first - their users actually use it ;-)
Patch on gerrit makes it functional again: https://gerrit.libreoffice.org/#/c/60432/
Muhammet Kara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=e98ac43ec42ff398ad489d6719960d595f0327be tdf#118881: Fix HTML parsing for personas It will be available in 6.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Muhammet Kara committed a patch related to this issue. It has been pushed to "libreoffice-6-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=2f52a8e0f1098a51631434129707cfb0b60fecb3&h=libreoffice-6-1 tdf#118881: Fix HTML parsing for personas It will be available in 6.1.2. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Seems resolved.
Cherry-picked to 6-0 as well: https://gerrit.libreoffice.org/#/c/60481/
removing keywords as this wasn't a regression caused by us
Verified in Version: 6.2.0.0.alpha0+ Build ID: 4e5f89d2d3511b6421b388ecaba2f61ada14d084 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: threaded @Muhammet Kara, thanks for fixing this!!
Muhammet Kara committed a patch related to this issue. It has been pushed to "libreoffice-6-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=6a113caf17974eb07a9f06ef09b1b1737d4d07bc&h=libreoffice-6-0 tdf#118881: Fix HTML parsing for personas It will be available in 6.0.7. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
On pc Debian x86-64 with master sources updated today, I don't reproduce this anymore. Thank you Muhammet! Let's close this one then.
Created attachment 147636 [details] Existing Firefox theme not found The Firefox theme URL was copy/pasted from the local (FR) Firefox website: https://addons.mozilla.org/fr/firefox/addon/libreoffice-4-light-ambiance/
Version: 6.1.3.2 (x64) Build ID: 86daf60bf00efa86ad547e59e09d6bb77c699acb CPU threads: 1; OS: Windows 6.1; UI render: default; Locale: fr-FR (fr_FR); Calc: group threaded (under Windows 7 pro 64b) Problems still present: -- themes download is slow. -- themes preview very small (way too small). This forces to accept a theme just for viewing the result (see next point). Very user-unfriendly. -- when one comes back from a tested theme to check for another, the user has to ask and download again (which is slow). -- only 9 themes are displayed. There's no way to know if there are more and, if there are, no (obvious) way to download these ones. -- copy/pasting a Firefox theme URL in the Term/URL textbox leads to an error (see attachment in #36) ex : https://addons.mozilla.org/fr/firefox/addon/libreoffice-4-light-ambiance/ It seems that LibO searches in the US Firefox website while the user obviously uses his Firefox national website (here: FR). -- pasting only the Firefox theme name in the Term/URL textbox leads to nothing: there's no feedback about what's going on (found? not found?) Terme searched: "libreoffice-4-light-ambiance" (without quotes)
(In reply to Jean-Francois Nifenecker from comment #37) > Version: 6.1.3.2 (x64) Have you tried with daily builds? Not sure that 6.1.2 means it was included in 6.1.3. Or just wait for 6.1.4 the next days.
(In reply to Jean-Francois Nifenecker from comment #37) > Version: 6.1.3.2 (x64) > Build ID: 86daf60bf00efa86ad547e59e09d6bb77c699acb > CPU threads: 1; OS: Windows 6.1; UI render: default; > Locale: fr-FR (fr_FR); Calc: group threaded > (under Windows 7 pro 64b) > > Problems still present: > -- themes download is slow. > > -- themes preview very small (way too small). This forces to accept a theme > just for viewing the result (see next point). Very user-unfriendly. > > -- when one comes back from a tested theme to check for another, the user > has to ask and download again (which is slow). > > -- only 9 themes are displayed. There's no way to know if there are more > and, if there are, no (obvious) way to download these ones. > > -- copy/pasting a Firefox theme URL in the Term/URL textbox leads to an > error (see attachment in #36) > ex : > https://addons.mozilla.org/fr/firefox/addon/libreoffice-4-light-ambiance/ > It seems that LibO searches in the US Firefox website while the user > obviously uses his Firefox national website (here: FR). > > -- pasting only the Firefox theme name in the Term/URL textbox leads to > nothing: there's no feedback about what's going on (found? not found?) > Terme searched: "libreoffice-4-light-ambiance" (without quotes) Please, create a follow-up bug for this. Set it back to FIXED
Need to verify the bug status again, as theme is not working for me on Libreoffice 6.1.5 @Windows 10.
(In reply to Jiero from comment #40) > Need to verify the bug status again, as theme is not working for me on > Libreoffice 6.1.5 @Windows 10. please see bug 123228