Closed Bug 623439 Opened 14 years ago Closed 14 years ago

Website changes for 2.1a1

Categories

(Camino Graveyard :: Product Site, defect)

All
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: alqahira, Assigned: alqahira)

References

Details

Attachments

(3 files)

Because at least initially we'll have some stuff to work up, filing so that we (I) don't forget:

1) preview.caminobrowser.org

2) blog post content

3) ua-messages/versions.js changes (first item of http://wiki.caminobrowser.org/Releases:Website_Checklist#Milestone_release )

4) "Preview" sign on contribute; not sure what or how we want to do this given the new layout on the page, or if there are other ways of promoting the alpha on the site that we may want to try
Flags: camino2.1a1+
5) The update definition and description.

Most of these are gated on settling the language used in the relnotes, since that language gets reused in most of the non-trivial changes here.
Depends on: 577528
Attached file Proposed preview.cbo
Here's the proposed preview site content.
Attachment #505150 - Flags: review?(samuel.sidler)
Attachment #505150 - Flags: feedback?(stuart.morgan+bugzilla)
Proposed cbo blog post:

<p>After over a year of hard work following the release of Camino 2, the Camino Project is proud to announce the <a href="http://preview.caminobrowser.org/">first preview release of Camino 2.1</a>.</p>
<p>Camino 2.1 Alpha 1 contains several notable improvements, including overhauled location bar autocomplete, a new history backend, the ability to hide the status bar, and enhanced support for web standards provided by version 1.9.2 of the Gecko rendering engine.</p>
<p>For more information and to download, please <a href="http://preview.caminobrowser.org/">visit our preview site</a> (users of <a href="http://caminobrowser.org/download/releases/nightly/">nightly builds</a> will be notified of the new preview release by software update and can install the new preview release by choosing <kbd class="menu">Check for Updates…</kbd> from the <kbd class="menu">Camino</kbd> menu.</span>).</p>
Comment on attachment 505150 [details]
Proposed preview.cbo

There are two things I noticed here :sigh:

1) We ought to port the <code> style from cbo
2) Somehow I missed zapping "Delete-as-back"

Both are fixed locally.
Comment on attachment 505150 [details]
Proposed preview.cbo

><!DOCTYPE html>
>   <h1>Camino 2.1 Alpha 4</h1>

s/4/1

>     <li><strong>Improved Plug-in Control:</strong> Camino now disables Java by default, and a new hidden preference allows disabling arbitrary plug-ins. To disable a plug-in, first find its name: choose âInstalled Plug-Insâ from the âHelpâ menu and look for the name of the desired plug-in in big, bold text, e.g. âShockwave Flashâ.  Then visit <code>about:config</code> and set the <code>camino.disabled_plugin_names</code> hidden preference to a unique prefix made up from the start of the plug-in name, e.g. âShockwâ.  Additional plug-ins can be disabled by separating the prefix strings with semicolons (<code>;</code>).

I think it's weird to talk about the hidden preference here. It makes this entire entry a mouthful. Can we put a page on the wiki and link to it here instead?

r=me
Attachment #505150 - Flags: review?(samuel.sidler) → review+
(In reply to comment #5)
> Comment on attachment 505150 [details]
> Proposed preview.cbo
> 
> ><!DOCTYPE html>
> >   <h1>Camino 2.1 Alpha 4</h1>
> 
> s/4/1

Gah, thought I got all of those :( Fixed.

> I think it's weird to talk about the hidden preference here. It makes this
> entire entry a mouthful. Can we put a page on the wiki and link to it here
> instead?

We can link to the Hidden Prefs section of the "docs to update for 2.1" page, though it's not really a user-friendly page: http://wiki.caminobrowser.org/Website:Documentation_Changes_for_2.1#Hidden_Prefs

Or were you suggesting a stand-alone ("temporary") page just for this pref for the 2.1 preview cycle?
(In reply to comment #6)
> Or were you suggesting a stand-alone ("temporary") page just for this pref for
> the 2.1 preview cycle?

Either way works, really. Hidden preferences in general aren't "user-friendly" so it wouldn't really bother me if the page as a whole wasn't.
> Known Issues:
>    * Delete no longer functions as a keyboard shortcut for Back.

WFM. I thought this bug had been fixed?
Comment on attachment 505150 [details]
Proposed preview.cbo

LGTM with the fixes previously mentioned.
Attachment #505150 - Flags: feedback?(stuart.morgan+bugzilla) → feedback+
(In reply to comment #8)
> > Known Issues:
> >    * Delete no longer functions as a keyboard shortcut for Back.
> 
> WFM. I thought this bug had been fixed?

(In reply to comment #4)
> Comment on attachment 505150 [details]
> Proposed preview.cbo
> 
> There are two things I noticed here :sigh:
> 
> 1) We ought to port the <code> style from cbo
> 2) Somehow I missed zapping "Delete-as-back"
> 
> Both are fixed locally.

;)
For reference, here's the update definition for 2.1a1; it's just a find/replace from 2.0a1.
And, aside from the signature (which comes from some other release), this is the update definition for 2.1a1.

Per irc, we're offering this update to any confused souls using 2.0.xpre nightlies as well as the usual 2.1a1pre nightly users (and I've tested with update-check-test to make sure 2.0.x release users don't get offered the update).
I also added a note just under "back up your profile" about history file changes (and the slow conversion first launch).

I tried to make screen.css use the same htaccess stuff we used for the js files (since the Preview div showed up unstyled), but it doesn't seem to be working. :(

<Files screen.css>
Header append Cache-Control "no-cache, must-revalidate"
</Files>

Otherwise, this is fixed.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
(In reply to comment #13)
> I tried to make screen.css use the same htaccess stuff we used for the js files
> (since the Preview div showed up unstyled), but it doesn't seem to be working.

By which I mean, Gecko seems to be ignoring it, or Gecko had cached the old file with the old lifetime/rules already and won't check again until some future time, or something :( The header itself is obviously being appended correctly.
The preview div came up correctly here, and I certainly have screen.css fairly fresh in the cache(s).
It's definitely still stuck here:

          Key: http://caminobrowser.org/css/screen.css
    Data size: 11549 bytes
  Fetch count: 7
Last modified: 2011-01-20 14:43:35
      Expires: 2011-01-24 22:01:59

Which appears to mean I'd last "caused Gecko to look at it" or something at 14:43 EST (just a few minutes before , and I guess it's not going to look again until 4 days have passed, the current HTTP headers be darned :P

So, presumably, worst-case, anyone who had loaded the stylesheet within the past 4 days *and got a fresh "lease" when doing so* has at most 4 days before the preview div starts to display properly.  From then (or a shift-reload, or a cache purge of some sort) on out, we ought to be able to change the CSS with impunity, safely for them. :P  There's still the possibility that this is something unique to me and my two Caminos on two Macs using two different OSes checked on two different networks ;)
I forgot to check earlier this week (and blew away all my TC profiles tonight), but my 1.6.11, which also had the "stuck" file, is now showing the preview div properly. :)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: