Bug 72 - default page doesn't redirect to website
Summary: default page doesn't redirect to website
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: x86_64 Linux
Priority: High normal
Target Milestone: Mageia 1
Assignee: Romain d'Alverny
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-02-17 00:07 CET by AL13N
Modified: 2014-05-08 18:05 CEST (History)
5 users (show)

See Also:
Source RPM: indexhtml
CVE:
Status comment:


Attachments

Description AL13N 2011-02-17 00:07:09 CET
User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101230 Mandriva Linux/1.9.2.13-0.2mdv2010.2 (2010.2) Firefox/3.6.13
Build Identifier: 

Description of problem:

script.js file missing in indexhtml page, which means the page doesn't 
redirect to www.mageia.org

perhaps it would be possible to include the code directly on the page and also to revamp the default static page as well...

Reproducible: 

Steps to Reproduce:
D Morgan 2011-02-25 00:04:13 CET

CC: (none) => dmorganec
Assignee: ahmadsamir3891 => bugsquad

Thierry Vignaud 2011-03-03 16:47:22 CET

CC: (none) => thierry.vignaud
Component: Installation => RPM Packages

D Morgan 2011-03-06 10:11:07 CET

CC: (none) => mageia-webteam
Assignee: bugsquad => rdalverny

Comment 1 Nicolas Vigier 2011-03-06 13:41:29 CET
Which page ?

CC: (none) => boklm

Comment 2 Manuel Hiebel 2011-03-06 13:52:39 CET
Maybe /usr/share/doc/HTML/index.html the default home page (in the alpha)

CC: (none) => manuel

Comment 3 AL13N 2011-03-06 15:25:19 CET
default homepage from indexhtml package.
Comment 4 AL13N 2011-03-06 15:26:44 CET
afaik the script.js still needs cleaning and isn't included? iirc rda was gonna fix it someday, so I filed this bug so it would be remembered.
Comment 5 Romain d'Alverny 2011-03-06 19:12:25 CET
The script is ok (rewritten and locally tested) and included in the package. But the spec file don't move it to the right place (and it does not rewrite one meta header at least).

Status: NEW => ASSIGNED

Comment 6 AL13N 2011-03-06 19:51:44 CET
i wanted to take a look at it, but i didn't see any commit yet.
Romain d'Alverny 2011-03-15 00:07:56 CET

Priority: Normal => High
Target Milestone: --- => Mageia 1

Thierry Vignaud 2011-03-15 09:22:06 CET

CC: thierry.vignaud => (none)

Comment 7 AL13N 2011-03-18 20:22:50 CET
still not ok on mageia 1 alpha 2, i would like to help, but i still cannot see an update on svn...

looking at the code, it seems that, we get directed to /usr/share/doc/HTML/index.html and not to /usr/share/mga/indexhtml/index.html (which does have images and script and everything)
AL13N 2011-03-18 20:23:02 CET

Blocks: (none) => 56

Comment 8 Romain d'Alverny 2011-03-18 23:28:46 CET
indexhtml specfile puts everything correct under mga/indexhtml while doc/HTML has only one single HTML file; and that's the place where the browser is expected to go.

See http://svnweb.mageia.org/packages/cauldron/firefox/current/SPECS/firefox.spec lines 295 and 301 where browser.startup.homepage property is set twice (duplicate) to doc/HTML/index.html

Btw, using distribution-specific tag "mga" in the path is not good.

So it involves a few other packages that depend on indexhtml (namely: evolution, midori, links, firefox).

To fix this, I suggest:
 * update and cleanup indexhtml specfile so that:
    - we don't create/populate /usr/share/doc/HTML anymore
    - we move the home page in /usr/share/indexhtml/
    - this is valid for welcome mail path too, we could move these in /usr/share/indexhtml/mail/ ? or /usr/share/welcomemail/ since we may move them into a separate package later?
 * so we will need to check dependent packages so that they use the correct path (however, only firefox and links seems to explicitly use the path in the spec file, so it may have been hardcoded somewhere else in other packages).
 * ensure it all works

Cc'ing ennael for advice, who last committed on these packages (among others). I can do the indexhtml part and firefox/links specfile, but not sure about the rest (mail path, evolution, midori). What about Konqueror by the way?

CC: (none) => ennael1

Comment 9 Ahmad Samir 2011-03-18 23:29:53 CET
(Doesn't block 56 as it's not an upgrade-related bug).

Blocks: 56 => (none)

Comment 10 AL13N 2011-03-19 00:12:21 CET
or...

you could base64 the script and image file and put it directly inside that single html file as a data blob.
Comment 11 Romain d'Alverny 2011-03-29 18:06:58 CEST
I pushed a few changes (after ahmad's review) in the previous days that should fix that:
 * http://svnweb.mageia.org/soft?view=revision&revision=711 (indexhtml)
 * http://svnweb.mageia.org/packages?view=revision&revision=76932 (indexhtml)
 * http://svnweb.mageia.org/packages?view=revision&revision=76933 (firefox)
 * http://svnweb.mageia.org/packages?view=revision&revision=76936 (links)

Not that indexhtml specfile is all clean now (there are hardcoded mga bits for the welcome mail), but it's another issue.
Comment 12 Ahmad Samir 2011-03-29 22:56:16 CEST
(In reply to comment #11)
> I pushed a few changes (after ahmad's review) in the previous days that should
> fix that:
>  * http://svnweb.mageia.org/soft?view=revision&revision=711 (indexhtml)
>  * http://svnweb.mageia.org/packages?view=revision&revision=76932 (indexhtml)
>  * http://svnweb.mageia.org/packages?view=revision&revision=76933 (firefox)
>  * http://svnweb.mageia.org/packages?view=revision&revision=76936 (links)
> 
> Not that indexhtml specfile is all clean now (there are hardcoded mga bits for
> the welcome mail), but it's another issue.

I missed one bit, sorry.

IINM, the %post section is redundant, as in Mageia indexhtml doesn't put any files in /usr/share/doc/HTML, I've removed it, (but won't submit until you review, you being the web/html guy and all :)).
Comment 13 Romain d'Alverny 2011-03-30 00:24:58 CEST
(In reply to comment #12)
> IINM, the %post section is redundant, as in Mageia indexhtml doesn't put any
> files in /usr/share/doc/HTML, I've removed it, (but won't submit until you
> review, you being the web/html guy and all :)).

What's the diff exactly? :-p (index, /usr/share/doc/HTML is not here anymore, but there's a %post thing to do nonetheless).
Comment 14 Ahmad Samir 2011-03-30 00:50:26 CEST
Ah, yes, but then the comment is wrong. I'll add it back and remove the comment (and we'll have to use /tmp/tmpfile).
Comment 15 Ahmad Samir 2011-03-30 01:16:36 CEST
The logic is wrong in the spec:
# add a default 
cat %buildroot/%_datadir/indexhtml/index.html | \
	sed "s/#PRODUCT_ID//" | \
	sed "s/#LANG/en/g" \
	> tmpfile
mv tmpfile %buildroot/%_datadir/indexhtml/index.html

%post
# done to prevent excludedocs to ignore the doc/HTML
mkdir -p  %_datadir/indexhtml
sed -i "s/#PRODUCT_ID/`cat /etc/product.id`/" \
    -i sed "s/#PRODUCT_ID/`cat /etc/product.id`/" \
    -i sed sed "s/#LANG/${LC_NAME/[-_]*}/g" \
%_datadir/indexhtml/index.html

in %post, %_datadir/indexhtml/index.html doesn't have #PRODUCT_ID or #LANG, they were already replaced in "add a default" in that same file.
Comment 16 Romain d'Alverny 2011-03-30 11:27:27 CEST
Ah yes. So keeping only one is better.

Can we keep only %post and remove the first one? or is there a case when %post may not be run on install?
Comment 17 Ahmad Samir 2011-04-06 19:35:43 CEST
This bug is fixed in indexhtml-1-3.mga1.

Closing, reopen if the bug isn't fixed for you.

Status: ASSIGNED => RESOLVED
Resolution: (none) => FIXED

Comment 18 AL13N 2011-04-06 20:43:58 CEST
still not working for me on my updated alpha 1 with FF.

how to reproduce:
 - install alpha 1
 - open FF and see that it doesn't work well, you see only "mageia" with a link.
 - update it completely
 - reboot
 - open firefox and and you see an error now: /usr/share/doc/HTML/index.html is not found.

i suspect firefox home page needs to be corrected as well...

Status: RESOLVED => REOPENED
Resolution: FIXED => (none)

Comment 19 Ahmad Samir 2011-04-06 20:56:20 CEST
It won't work with old firefox profiles, as the:
user_pref("browser.startup.homepage", "file:///usr/share/doc/HTML/index.html");

is already in ~/.mozilla/firefox/<profile name>/prefs.js. This is not the scope of this report.

Also note that no rpm post scriptlet will/should ever touch a config file in the user's /home dir, and that whatever firefox default/system-wide default browser.startup.homepage is, it won't affect a setting in prefs.js, as prefs.js overrides system-wide settings...

I guess a note could be dropped in the errata about this issue, with a sed command to fix it for the user, or explaining how to edit ~/.mozilla/firefox/<profile name>/prefs.js manually...
Comment 20 AL13N 2011-04-06 21:36:35 CEST
i will test on a new installation, if it's ok there, then i consider this closed as we should not "support" a non-stable release.

I will check a little while later.
Comment 21 Ahmad Samir 2011-04-06 23:31:28 CEST
No need of a new installation, just rename ~/.mozilla or test in a new user account.

I don't see where non-stable release enter here, this will affect any old firefox profile with any upgrade from an mdv release.
Comment 22 AL13N 2011-04-07 08:42:16 CEST
oh, ic that you are right. didn't think about upgrade from mdv...


in that case, i would suggest keeping the /HTML/ directory, and perhaps linking the files in indexhtml/ to HTML/ ?
Comment 23 Romain d'Alverny 2011-04-07 10:13:09 CEST
That looks like a good option. Ahmad, wdyt?
Comment 24 Ahmad Samir 2011-04-07 17:21:06 CEST
(In reply to comment #23)
> That looks like a good option. Ahmad, wdyt?

Then the symlink will have to be there for a very long time; the two options are:
1) the symlink is created and kept there for as long as 2010.x is supported (that somehow defines the reasons the files location were changes in indexhtml); Mageia ideally supports upgrading from 2010.x
2) no symlink is created and a note is dropped in the Errata, it's as simple as a single sed command on prefs.js in the user's profile, and is a one time issue.
Comment 25 Romain d'Alverny 2011-04-07 17:29:41 CEST
(In reply to comment #24)

My only concern here is for the upgrade path from 2010.x, so that users that didn't change their start page in the meantime do get the Mageia one:
 - so we should not change prefs.js anyway;
 - a symlink to be created only for Mageia 1 would be ok - later upgrades should not remove this symlink, right?
Comment 26 Michael Scherer 2011-04-07 17:50:18 CEST
Another solution would be to set this in a shell wrapper when firefox is started ( ie, the sed stuff ).
But this could change profile page when people do not want, so that's not ideal.

CC: (none) => misc

Comment 27 Ahmad Samir 2011-04-07 20:12:15 CEST
(In reply to comment #25)
> (In reply to comment #24)
> 
> My only concern here is for the upgrade path from 2010.x, so that users that
> didn't change their start page in the meantime do get the Mageia one:
>  - so we should not change prefs.js anyway;
>  - a symlink to be created only for Mageia 1 would be ok - later upgrades
> should not remove this symlink, right?

The point is, if the user doesn't edit prefs.js to change the pref, it'll be there forever, people usually use the same profile as it contains bookmarks, tags, saved passwords... etc.
Comment 28 AL13N 2011-04-07 21:12:30 CEST
the symlinks looks like a big maintainability issue, but not having symlinks will probably create alot of noise, especially with reviewers who might "test" our upgrade path...

so what if the few symlinks are there? is that a real problem? is it the end of the world if the user has it in his profile for 10years or more? not imho.

what about other browsers?
Comment 29 Romain d'Alverny 2011-04-08 10:15:08 CEST
(In reply to comment #27)
> The point is, if the user doesn't edit prefs.js to change the pref, it'll be
> there forever, people usually use the same profile as it contains bookmarks,
> tags, saved passwords... etc.

We can afford having their home page broken by a later release/upgrade - if they didn't customize it - when we would remove the symlink (we should  perhaps leave a hint to this bug in the spec file?).

Here the crucial thing is really the Mandriva 2010.x/Mageia 1 transition where we should not leave people in the void.

(In reply to comment #28)
> what about other browsers?

Opera doesn't use this page afaik; links does and has been updated, however I don't know if there's a user prefs file for it.
Comment 30 Ahmad Samir 2011-04-08 17:41:00 CEST
(In reply to comment #29)
> (In reply to comment #27)
> > The point is, if the user doesn't edit prefs.js to change the pref, it'll be
> > there forever, people usually use the same profile as it contains bookmarks,
> > tags, saved passwords... etc.
> 
> We can afford having their home page broken by a later release/upgrade - if
> they didn't customize it - when we would remove the symlink (we should  perhaps
> leave a hint to this bug in the spec file?).
> 
> Here the crucial thing is really the Mandriva 2010.x/Mageia 1 transition where
> we should not leave people in the void.
> 

I see your point, (so we break it for Mageia 2 :)).

Symlink added and a new package submitted.
Comment 31 Romain d'Alverny 2011-05-05 14:10:38 CEST
Status update? Or can we close this one?
Comment 32 Ahmad Samir 2011-05-05 18:09:26 CEST
Last time I tested, it worked as expected.
Comment 33 Romain d'Alverny 2011-05-05 18:17:32 CEST
Ok, then; thanks.

Status: REOPENED => RESOLVED
Resolution: (none) => FIXED

Nicolas Vigier 2014-05-08 18:05:32 CEST

CC: boklm => (none)


Note You need to log in before you can comment on or make changes to this bug.