1267830 - Add link on SeaMonkey homepage to privateinternetaccess.com

Status: RESOLVED FIXED

(SeaMonkey :: Project Organization, defect)

Description

[Frank Wein [:mcsmurf]]

(Not a real security problem, but this one should stay internal to SeaMonkey project organization)

We need to add a link to privateinternetaccess.com to our homepage, it must stay there for at least one year.
This needs to happen until 1st of Mai (or shortly after).

Comment 1

[Justin Wood (:Callek)]

With the sec flag you provided, only me and people CC'd can see this bug, can you add a CC for whomever needs to see this and/or work on this.

I'm not sure if there is another "hidden to us" group we can use thats not sec-* because this also encrypts the bugmail on us. And *may* show up in moco's sec triage lists.

Comment 2

[Frank Wein [:mcsmurf]]

Hm yes, I saw some mail to security...was not intended, but currently I know of no other solution.

Comment 3

[Frank Wein [:mcsmurf]]

Jens: Just FYI, I will attach a patch here very soon. The link will probably include a logo from them (but I have to ask them if we can use it).

Comment 4

[:Gijs (he/him)]

(In reply to Justin Wood (:Callek) from comment #1)
> With the sec flag you provided, only me and people CC'd can see this bug,
> can you add a CC for whomever needs to see this and/or work on this.

And anyone in core-security-release...

> I'm not sure if there is another "hidden to us" group we can use thats not
> sec-* because this also encrypts the bugmail on us. And *may* show up in
> moco's sec triage lists.

It also emails people who watch for new sec bugs (and who are in the relevant security groups), like me.

(In reply to Frank Wein [:mcsmurf] from comment #0)
> We need to add a link to privateinternetaccess.com to our homepage, it must
> stay there for at least one year.
> This needs to happen until 1st of Mai (or shortly after).

Normally bugs have some kind of motivation if it's not obvious. Why does this link need adding?

Comment 5

[Frank Wein [:mcsmurf]]

Because of sponsorship reasons.

Comment 6

[Frank Wein [:mcsmurf]]

Attachment: Patch

Jens, what do you think about this patch? I've placed the banner right below the left navigation bar. I guess another possibility would be more at the bottom of the page. Actually the only requirement here is a link on our main page. But then, I think, we also should not "hide" it at the bottom somewhere.

Comment 7

[Frank Wein [:mcsmurf]]

Attachment: Better patch

This one is better, the old patch contained some test changes.

Comment 8

[Jens Hatlak (:InvisibleSmiley)]

Comment on attachment 8747498 [details] [diff] [review]
Better patch

I see several issues with this.
Example: http://stage.seamonkey-project.org/legal/

* Image URL must be absolute (start with a slash) in order to work with subfolders like legal/.
* Missing line break (<br>) after the "Sponsored by".
* Technically I'd move the added HTML outside the itemcount IF.
* The added HTML appears twice (in two different spots) on pages that have navigation subitems in the sidebar. Haven't checked in detail, maybe moving the additions outside all IFs, or behind the crumblist block, would fix it.
* Personally I'd reduce the "Sponsored by" font size a bit, e.g. with <span style="font-size: x-small">.

Comment 9

[Frank Wein [:mcsmurf]]

Attachment: Patch

Thanks for the feedback, moving the HTML outside the if seems to work fine! IMHO the resulting website looks fine now on the staging server.

Comment 10

[Jens Hatlak (:InvisibleSmiley)]

Comment on attachment 8747554 [details] [diff] [review]
Patch

Review of attachment 8747554 [details] [diff] [review]:
-----------------------------------------------------------------

::: lib/sidebar.tmpl
@@ +66,5 @@
>         PROCESS crumblist cnode=cnode.getParentNode();
>       END;
>     END;
> +
> +   "<span style=\"font-size: x-small\">Sponsored by:</span><br/>\n";

The pages are HTML 4 strict, not XHTML. Please use <br> instead of <br/>.

Comment 11

[Frank Wein [:mcsmurf]]

Actually, there's still a mistake here: The link should only be visible on the front page, not on every page.

Comment 12

[Jens Hatlak (:InvisibleSmiley)]

Ideally there'd be a way to determine which page is currently being processed. Don't know if that exists, though. Maybe you could define some variable in src/index.en.html and query that where needed, but you might have to reset it somehow.

It's probably easier to modify the HTML being added by wrapping it in a <div> with style="display:none" and id="something" and then adding a CSS rule to src/index.en.html that makes the div visible on that page only, e.g.

<style type="text/css">
  #something { display:block; /* or maybe inline-block? */ }
</style>

Not sure whether that would stop the image from being loaded on the other pages, though. Could be fixed by only loading the image via CSS in above rule.

Comment 13

[Frank Wein [:mcsmurf]]

Attachment: Patch

IF template.name == "index.en.html";
does the trick. The CSS solution is also interesting though :)

Comment 14

[Frank Wein [:mcsmurf]]

Pushed: https://hg.mozilla.org/SeaMonkey/seamonkey-project-org/rev/d9e5f275e4ea

Comment 15

[Frank Wein [:mcsmurf]]

Everything seems to look fine, fixed!