Bug #7329
Adapt the Unsafe Browser for the Windows 8 camouflage
100%
Description
First of all the unsafe-browser script wasn’t updated to run the Windows 8 camouflage activation script for the clearnet user, so it tries and fails to run the removed Windows XP camouglage activation script.
Second, even if we fix the above, the gsettings/@dconf@ calls will fail since there’s no dbus session for the clearnet user.
Third, even with a dbus session, the Windows 8 camouglage activation script seems to return failure, failing the unsafe-browser start.
All in all, I think the following patch will fix everything:
--- a/config/chroot_local-includes/usr/local/sbin/unsafe-browser
+++ b/config/chroot_local-includes/usr/local/sbin/unsafe-browser
@@ -168,7 +168,7 @@ user_pref("lightweightThemes.isThemeSelected", true);
user_pref("lightweightThemes.usedThemes", "[{\"id\":\"1\",\"name\":\"Unsafe Browser\",\"headerURL\":\"file:///usr/share/pixmaps/red_dot.png\",\"footerURL\":\"file:///usr/share/pixmaps/red_dot.png\",\"textcolor\":\"#FFFFFF\",\"accentcolor\":\"#CC0000\",\"updateDate\":0,\"installDate\":0}]");
EOF
else
- chroot ${CHROOT} sudo -H -u clearnet tails-activate-winxp-theme
+ chroot ${CHROOT} sudo -H -u clearnet sh -c 'eval `dbus-launch --auto-syntax` && tails-activate-win8-theme' || :
fi
# Set the name (e.g. window title) of the browserHistory
#1 Updated by anonym 2014-05-29 06:31:20
- blocks
Feature #6342: Update Windows camouflage for GNOME3 added
#2 Updated by intrigeri 2014-05-29 07:08:57
- Subject changed from Windows 8 camoufalge breaks Unsafe Browser to Windows 8 camouflage breaks the Unsafe Browser
#3 Updated by intrigeri 2014-05-29 07:10:40
Why the || :? The Windows camouflage script already lacks error checking and set -e, iirc.
#4 Updated by anonym 2014-06-10 19:00:51
intrigeri wrote:
> Why the || :? The Windows camouflage script already lacks error checking and set -e, iirc.
Note that the diff is against the unsafe-browser script, which does set -e. The call of tails-activate-winxp-theme will return an error since it tries to modify files not present in clearnet’s home, hence the need for || : but the real fix should be that those parts of the code only are run if the required directories exist.
Any way, now that tails-activate-winxp-theme modifies the user’s iceweasel configuration my fix won’t be this simple.
#5 Updated by anonym 2014-06-11 06:48:01
- QA Check changed from Dev Needed to Ready for QA
- Feature Branch set to bugfix/7329-unsafe-browser-with-win8-camouflage
This branch makes the Unsafe Browser start when Windows 8 camouflage is activated, and also applies the Windows 8 theme to the browser.
#6 Updated by anonym 2014-06-11 06:49:20
Oh, and the branch is based on feature/6342-update-camouflage-for-gnome3.
#7 Updated by anonym 2014-06-11 07:46:56
- Assignee changed from anonym to intrigeri
- QA Check changed from Ready for QA to Dev Needed
#8 Updated by intrigeri 2014-06-11 08:05:16
- Assignee changed from intrigeri to anonym
- QA Check changed from Dev Needed to Ready for QA
anonym wrote:
> Oh, and the branch is based on feature/6342-update-camouflage-for-gnome3.
… so these two branches are blocking each other, and need to be merged in lockstep.
#9 Updated by intrigeri 2014-06-11 08:32:14
- QA Check changed from Ready for QA to Dev Needed
After discussing this a bit with anonym:
- wiki/src/contribute/design/Unsafe_Browser.mdwn should be updated, as part of the implementation is now in /usr/local/bin/tails-activate-win8-theme, apparently
- in the commit message for d93e70d9, it’s very unclear that “that script” means “tails-activate-win8-theme” (anonym explained me on IRC, else I wouldn’t have got it)
- I’m curious why we don’t need to remove stuff from
${CHROOT}/etc/iceweasel/searchpluginsanymore [ -d "$HOME/.claws-mail/clawsrc" ]should be[ -d "$HOME/.claws-mail" ]instead- now that
cat >> ${HOME}/.mozilla/firefox/default/user.js <<EOFis indented, I’d rather see it use<<-, and indent the following lines (until EOF) with tabs. - “initializing” a fresh Unsafe Browser profile by merely copying what’s in
/etcmight do less than what FF does when initializing that profile itself; it might be more reliable to generate the profile in a much way that we do inconfig/chroot_local-hooks/14-generate-iceweasel-profile
#10 Updated by anonym 2014-06-11 16:10:39
- Subject changed from Windows 8 camouflage breaks the Unsafe Browser to Adapt the Unsafe Browser for the Windows 8 camouflage
- Assignee changed from anonym to intrigeri
Renaming the ticket and broadening its horizon since there are more issues vs. the new Windows 8 camouflage. See the child ticket Bug #7395.
intrigeri wrote:
> After discussing this a bit with anonym:
>
> # wiki/src/contribute/design/Unsafe_Browser.mdwn should be updated, as part of the implementation is now in /usr/local/bin/tails-activate-win8-theme, apparently
Well, nothing has changed since the Windows XP camouflage times, really, since it also called it. I’ll add a short line.
> # in the commit message for d93e70d9, it’s very unclear that “that script” means “tails-activate-win8-theme” (anonym explained me on IRC, else I wouldn’t have got it)
Should I rewrite the history to fix the commit message?
> # I’m curious why we don’t need to remove stuff from ${CHROOT}/etc/iceweasel/searchplugins anymore
Hmm, that’s a mistake. I thought search plugins were copied into the profile on creation, but apparently they are looked for in the global profile, similar to extensions. Any way, we don’t have the search bar in any browser (Unsafe or not) when in camouflage mode: Bug #7395. Therefore we may want to stop fiddling with the search engine plugins completely, right?
> # [ -d "$HOME/.claws-mail/clawsrc" ] should be [ -d "$HOME/.claws-mail" ] instead
Fixed now.
> # now that cat >> ${HOME}/.mozilla/firefox/default/user.js <<EOF is indented, I’d rather see it use <<-, and indent the following lines (until EOF) with tabs.
Are you also suggestion that I switch to tab indentation everywhere in the script? Otherwise the indentation will be mismatched.
Frankly, I didn’t know about <<- and that alone makes it doubtful to me that it’s a readability improvement at all.
> # “initializing” a fresh Unsafe Browser profile by merely copying what’s in /etc might do less than what FF does when initializing that profile itself; it might be more reliable to generate the profile in a much way that we do in config/chroot_local-hooks/14-generate-iceweasel-profile
On second thought, the profile /etc/skel/.mozilla/firefox/default is generated in that exact way, in the hook you mention, so I don’t think there’s any concern here, right?
#11 Updated by anonym 2014-06-11 16:12:13
- Assignee changed from intrigeri to anonym
The ticket had changed while I was editing it (which it hadn’t…), so assignee changed without my intention. Reverting.
#12 Updated by anonym 2014-06-11 16:40:27
- Category changed from 183 to Camouflage
#13 Updated by intrigeri 2014-06-11 18:21:57
> Should I rewrite the history to fix the commit message?
I would find it helpful next time we have to dig into Git history to
understand why things are the way they are.
> Therefore we may want to stop fiddling with the search engine
> plugins completely, right?
Yes, unless we decide that not hiding the search bar in the Unsafe
Browser in camouflage mode is the best visual indicator we can get.
>> # now that cat >> ${HOME}/.mozilla/firefox/default/user.js <<EOF is indented, I’d
>> rather see it use <<-, and indent the following lines (until EOF) with tabs.
> Are you also suggestion that I switch to tab indentation everywhere in the script?
> Otherwise the indentation will be mismatched.
Certainly not :) It’s just that <<- only works with tabs, IIRC.
> Frankly, I didn’t know about <<- and that alone makes it doubtful to me that it’s a readability improvement at all.
Oh, OK. Your call, then.
> On second thought, the profile /etc/skel/.mozilla/firefox/default is generated in that exact way, in the hook you mention, so I don’t think there’s any concern here, right?
Right :)
#14 Updated by intrigeri 2014-06-12 03:55:28
- Status changed from Confirmed to In Progress
#15 Updated by anonym 2014-06-12 09:43:47
- Status changed from In Progress to Confirmed
intrigeri wrote:
> > Should I rewrite the history to fix the commit message?
>
> I would find it helpful next time we have to dig into Git history to
> understand why things are the way they are.
Fixed and force-pushed. The diff should be empty with your local branch and the new remote branch.
> > Therefore we may want to stop fiddling with the search engine
> > plugins completely, right?
>
> Yes, unless we decide that not hiding the search bar in the Unsafe
> Browser in camouflage mode is the best visual indicator we can get.
I think we already have a solution in place, see my new comment on Bug #7395.
#16 Updated by anonym 2014-06-12 14:12:50
- Assignee changed from anonym to intrigeri
- QA Check changed from Dev Needed to Ready for QA
Everything should be fixed now.
#17 Updated by intrigeri 2014-06-12 14:32:06
Congrats! I’ll look at it tomorrow, so that you have a chance to fix
this if needed before you leave… and it’ll be yet another great way
for me to sidetrack away from Bug #7345 :]
#18 Updated by intrigeri 2014-06-13 04:11:20
- Status changed from Confirmed to Fix committed
- Assignee deleted (
intrigeri) - QA Check changed from Ready for QA to Pass
Merged into feature/6342-update-camouflage-for-gnome3.
#19 Updated by intrigeri 2014-06-13 04:13:15
- blocked by deleted (
Feature #6342: Update Windows camouflage for GNOME3
#20 Updated by intrigeri 2014-06-13 04:13:45
- Status changed from Fix committed to Resolved
- Parent task set to
Feature #6342