Closed
Bug 65241
Opened 24 years ago
Closed 23 years ago
Prefs: add Content pack panel with Download button.
Categories
(SeaMonkey :: Preferences, defect, P1)
SeaMonkey
Preferences
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla0.9.3
People
(Reporter: jaimejr, Assigned: paulkchen)
References
()
Details
(Keywords: intl, Whiteboard: fixed on branch, broken on trunk)
Attachments
(5 files)
(deleted),
text/html
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
image/jpeg
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review |
Creating new bug to remove Netscape Confidential information. Formerly bugzilla
64145.
Reporter | ||
Comment 1•24 years ago
|
||
Since we are separating language UI from regional content, we will need to
change the View menu to reflect the change.
I propose we:
1) Remove "Set Language/Region" from the View menu
2) Add "Select Language" and "Select Regional Content" to the View menu, under
Apply Theme. Thereby grouping all Navigator customization features in one area.
Nominating for nsbeta1.
------- Additional Comments From Jaime Rodriguez, Jr. 2001-01-02 17:57 -------
Adding nsbeta1 and intl keywords.
Reporter | ||
Comment 2•24 years ago
|
||
------- Additional Comments From timeless@mac.com 2001-01-02 21:13 -------
to bleeping with this- Request permission to remove these menus from mozilla.
If Commercial wants them they'll probably have to keep them in their tree.
Waiting for mpt to tell me he disagrees. Ben I'd like your input too.
------- Additional Comments From Matthew Thomas (mpt) 2001-01-02 22:38 -------
(1) can not be done. There isn't a `Set Language/Region' item in the View menu
(or any other menu, for that matter), so it can't be removed. (But see also bug
61162.)
(2) should not be done. Including these two new menu items would be very bad.
In the list of things users will do most often with Mozilla, changing their UI
language and their regional content will come in at about 7043 and 7044 on the
list. No way do they belong in the menus.
------- Additional Comments From Jaime Rodriguez, Jr. 2001-01-03 08:51 -------
Commercial does want them. There is a "Set Language/Region" item in the
Commercial release of 6.0.
------- Additional Comments From tao@netscape.com 2001-01-03 12:24 -------
The Mozilla equivalent of Netscape6's "Set Language/Region" menuitem is
"Languages and Web Content". This bug calls for moving "Set Language/Region" and
"Apply Theme" into a sub-menu group: "Customization". The UI details is yet to be
defined.
>(2) should not be done. Including these two new menu items would be very bad.
>In the list of things users will do most often with Mozilla, changing their UI
>language and their regional content will come in at about 7043 and 7044 on the
>list. No way do they belong in the menus.
Not sure if this is true for international users.
------- Additional Comments From timeless@mac.com 2001-01-03 13:58 -------
imo, menus are for quick changes that require little thought and no preview.
Users should not need to make multiple visits to the same part of a menu to get
something they like.
In English, that means if the user is likely to need to change 5 things to be
happy [Theme, UILanguage, ProvidedContent Region, Prefered Browsing Language,
Fonts for web content] then the user needs a dialog.
This dialog content fits well w/ the current preferences dialog and there does
not seem to be any reason to use the menu system.
I know moz has languages/web content, it's a misnomer. I think it really meant
languages/provided content.
questions that mpt and co would want you to answer:
Does the user intend to frequently change these settings? Will the user need
to see a preview before making a decission? Will the user be able to recognize
this item when it's written in the wrong language?
This last one is probably ****ing, because I know that I can't read
"Languages/Web Content" if it's written in arabic. However, my experience w/
Netscape4 tells me where the preferences menu is, and it also hints about that
dialog's layout. I can imagine finding my way to something that said English.
The others also argue against your cause. The average user probably changes ui
languages less than .1 times per install. This is based on the assumption that
mozilla picks the default language based on the system default instead of
assuming everyone uses English. And if you haven't filed a bug to allow
mozilla/netscape to ask for permission to retrieve a translation based on the
user's system default then please do so now.
------- Additional Comments From Matthew Thomas (mpt) 2001-01-03 14:01 -------
What is an `international user'? Is that one of those weird people like me, who
have the audacity to live somewhere other than the US? Or is it someone with a
split personality, who is compelled to change the language of their Mozilla
user interface every hour or so, and so needs a menu item for that express
purpose?
A feature which will only be used only once or twice in the lifetime of a
Mozilla user profile simply does not deserve its own menu item, regardless of
how badly the developers of the feature want to show it off. I suggest this bug
be wontfixed and bug 64147 be fixed instead. If `commercial' (by which I assume
you mean Netscape Communications Corporation) want to confuse their users by
putting such a menu item in their distribution, they can file that in their own
bug database.
------- Additional Comments From tao@netscape.com 2001-01-03 14:49 -------
1. I agree that "Set Language/Region" is more proper than "Language and web
Content". We could take the opportunity of revamping "View" menu to fix
it.
2. Prefs dialog is certainly the best place to change multiple user preferences
at the same time. However, menu item has the advantage of exposing the
feature to end users. Placing language/region setting menuitems adjacent to
international related menuitem improves their visibility.
3. Answers to your questions:
>questions that mpt and co would want you to answer:
>Does the user intend to frequently change these settings?
For language/region, it depends on whether you are a multiple-lingual person
and whether this client installation is shared by person (family) with
multi-culture background.
The original goal is to provide the flexbility of switching UI languages and
regional content with the same client installation. In the past, we need
different client installation to do so.
For road warriors that make international trip, the capability of switching
regional contents should be convenient.
>Will the user need to see a preview before making a decission?
As you suggested, menuitems are for easy access and tasks that do not need
preview.
Will the user
> be able to recognize this item when it's written in the wrong language?
Not sure what you meant. But, if you are referring to the UI language, the
rationale is user won't switch to a language that s/he does not read.
4. Using system locale as the default is a reasonable solution for picking
the default UI language and regional content. See
http://bugzilla.mozilla.org/show_bug.cgi?id=44070.
5. > What is an `international user'?
Please pardon my terms. I obviously used the wrong word. I meant
"multi-lingual" or multi-cultural users like me. One usage of this feature is
the kiosk mode client installed in public area/resort like Disney world and
internation airport. Net appliance is good candidate, too.
------- Additional Comments From Reinout van Schouwen 2001-01-11 15:45 -------
I'm not quite sure this is the right bug to add this question to, but I hope so.
The newsgroup Date column displays time in AM/PM format. I'd like to have it in
24h format. I don't mind if the Mozilla interface is in English but having an
option to use different date/time formats would be nice...
This is starting to get pretty complicated. Now there is a request for adding
time display prefs too. I thinks this calls for a UI that would let users
define "Locales" in a locale manager, that is you capture settings under
one 'Locale" name, that you will be able to switch using the view menu. Most
likely users will know which combinations they need most frequently, there is
no need for exposing all the complicated setting in the view menu and thereby
penanlizing mono-lingual users.
> This is starting to get pretty complicated. Now there is a request for adding
>time display prefs too.
There are other locale categories such as MONETARY, CTYPE, COLLATE, etc.
Changing them either statically or dynamically is a more complicate issue
than changing chrome locale provider. It's more of an enhancement request.
>I thinks this calls for a UI that would let users
>define "Locales" in a locale manager, that is you capture settings under
>one 'Locale" name, that you will be able to switch using the view menu. Most
>likely users will know which combinations they need most frequently, there is
>no need for exposing all the complicated setting in the view menu and thereby
>penanlizing mono-lingual users.
As you suggested, it probably is not a good idea to put settings of all locale
types in View menu. A better place might be in the Prefs dialog.
However, the short term solution is to provide quick switch of chrome locale
provider.
Let's attack the "Locale Manager" UI in future release.
Reporter | ||
Comment 5•24 years ago
|
||
Met with German on Wednesday, 02.21.01. We reviewed the feature and its future
versioning. Addtionally, we provided him the original Language Pack doucment for
his use. Next steps, will be for German to propose new UI specification to
address the separation of Language and Content.
I have better understanding now what the separation of UI Language and Regional
content packs mean. I am now of the belief that the change of the UI Language is
probably much less frequent than that of regional packs, meaning the UI language
selection should prob be a pref which is then peristed in the profile.
Regional Content Packs however are envisioned to be changed frequently, thus I
would assume they are similar to themes, meaning we should add them to the View
menu similar to "Apply Theme". Adding them to prefs is optional.
Reporter | ||
Comment 7•24 years ago
|
||
Reassigning to German for UI specification.
Assignee: hangas → german
friendly reminder that UI freeze is March 1st, with approved changes only till
March 15th
Comment 9•24 years ago
|
||
What proportion of Mozilla users meet all four of the following criteria:
(1) regularly travel to different towns/countries;
(2) take their computer with them when travelling to a different town/country;
(3) use content provided by mozilla.org (or netscape.com, or whoever), rather
than their own selection of bookmarks etc, to keep up with local news/events;
(4) do not want to keep up with news/events in their home town/country --
preferring access to these to be deleted and replaced with access to
news/events in their destination -- when travelling?
If that proportion is less than 20 percent (and I suspect it's less than 0.5
percent), I'm going to kick this bug into the Derivatives > Netscape 6 component.
I don't mind such menu items being put in the `View' menu for Netscape users to
laugh at (though I'd certainly advise Netscape against it), but please, please
keep them out of Mozilla.
Comment 10•24 years ago
|
||
Triage Team marking nsbeta1+ and 0.9
Comment 11•24 years ago
|
||
Chaning the qa contact on these bugs to me. MPT will be moving to the
owner of this component shortly. I would like to thank him for all his hard
work as he moves roles in mozilla.org...Yada, Yada, Yada...
QA Contact: mpt → zach
Summary: Need to add "Select Language" and "Select Regional Content" to View menu → "View" menu: Need to add "Select Language" and "Select Regional Content"
Reporter | ||
Comment 12•24 years ago
|
||
Adding Andreas to cc: list.
Comment 13•24 years ago
|
||
Adding Yuying to cc: list.
Comment 14•24 years ago
|
||
Changing milestone because German is on vacation until we close for 0.9.
Priority: -- → P3
Target Milestone: mozilla0.9 → mozilla0.9.1
Reporter | ||
Comment 15•24 years ago
|
||
Paul - I guess we will have to wait for German, but we defintely needed done
ASAP, so we can get some testing cycles on the changes to the feature.
Question? - German finished the spec, is he also writing the code, or is that
something Ben does?
Reporter | ||
Comment 16•24 years ago
|
||
German - Tao had indicated to me last week, that all his bugs were now accepted
by Ben to resolve for M0.9.1. This one looks like it hasn't been picked up?!?!?!
Ben - Will you accpet this one, or should I get someone in ICP to fix it?
Adding ftang and bobj to cc: list.
Bob - Tao said, you would be the best one to help in his absence.
Reporter | ||
Comment 17•24 years ago
|
||
Assigning a P2 | Blocker to this one. It needs to be fixed ASAP.
Changing "Select" to "Set". Menu listing should now be "Set Language" and "Set
Region".
Vishy - This one is our Number 1 priority. Please see if we can get this fixed
this week.
Severity: normal → blocker
Priority: P3 → P2
Summary: "View" menu: Need to add "Select Language" and "Select Regional Content" → "View" menu: Need to add "Set Language" and "Set Region"
Comment 18•24 years ago
|
||
I dont think we can do it this week. This is the first I'm seeing this bug.
Comment 19•24 years ago
|
||
Jamie, Vishy, German, please see mpt's comment above. This should not be
implemented until that question is answered. Please don't use some Netscape
secret freeze date to rush in changes to the UI which have standing objections.
Thank you.
Reporter | ||
Comment 21•24 years ago
|
||
Asa/MPT - Code to seperate the Language UI from Content has already been
checked-in. The reuqested UI changes address these changes, so that feature is
not broken, and the user can customize their settings, much like Theme
switching.
Comment 22•24 years ago
|
||
jaime, you are talking about adding items to the UI which currently aren't
there, correct? If that is the case and there is a standing objection from mpt
or questions still to be answered about the addition of this menu item, then
this is not sufficiently ready for checkin. Your comment seems to imply that
this is the only, or already decided upon (which it is definitely not) method
for making the existing feature available to the user. That is clearly not the
case. German hasn't even yet responded to your requests for a spec on 2/23 and
his prior commented assumption that this was similar to themes was challenged by
mpt and no followup has happened.
Reporter | ||
Comment 23•24 years ago
|
||
Asa - The UI already exist (see View | Set Language/Region). The feature already
exist. This is an enhancment to seprate the Language UI from Content Packs. Pls
see bugzilla 76551 which has been logged against the feature.
German - Please attach your spec to this bug.
Comment 24•24 years ago
|
||
I may be way off base with this but isn't it the case that you're plan is
replacing one rarely used menuitem with two rarely used menuitems and mpt's and
other's suggestion is that we don't want to add menu items (one becoming two is
adding a menu item) for tasks which most users are very unlikely to use with any
regularity.
I've seen bug 76551 and it is clear to me that the functionality is currently
inaccessible. What isn't clear to me is why you think that two menuitems on the
view menu is the only way to expose this functionaliy. That it is currently
unavailable is not justification for adding access points to inappropriate
places in the UI.
Comment 25•24 years ago
|
||
I think a comment from German n 2001-02-23 in Bug 65253 is pertinent:
---
"I have better understanding now what the separation of UI Language and Regional
content packs mean. I am now of the belief that the change of the UI Language is
probably much less frequent than that of regional packs, meaning the UI language
selection should prob be a pref which is then peristed in the profile.
Regional Content Packs however are envisioned to be changed frequently, thus I
would assume they are similar to themes, meaning we should add them to the View
menu similar to "Apply Theme". Adding them to prefs is optional."
---
While I agree that changing Region Content Packs would probably be a much more
frequent activity, I would say that changing the UI language could be something
that would be as frequent as changing the profile, as in the case where 2 people
sharing a computer are fluent in two different languages. I would just add
that another browser out there forces the user to click through 3 windows
(internet options>languages>change) before the UI language can be changed. This
can be quite cumbersome--something I would steer clear of here.
Comment 26•24 years ago
|
||
and Ben Goodger's response to German (from bug 65251):
------- Additional Comments From Ben Goodger 2001-02-28 01:05 -------
German writes:
"I have better understanding now what the separation of UI Language and Regional
content packs mean. I am now of the belief that the change of the UI Language is
probably much less frequent than that of regional packs, meaning the UI language
selection should prob be a pref which is then peristed in the profile."
Agreed. I would go so far as to say that there should be *no* UI for this at all
in seamonkey, at least by default(*). If, after the novelty wears off, the
average user changes skins maybe (at most) four times per year, how often is
language pack going to be changed? I'm not concerned with international users
with special needs here, I'm talking about people using the product in a single
configuration.
"Regional Content Packs however are envisioned to be changed frequently, thus I
would assume they are similar to themes, meaning we should add them to the View
menu similar to "Apply Theme". Adding them to prefs is optional."
I would tend to discourage adding any such menu items to an already overcrowded
menu as these options are only likely to be meaningful to the tiny minority of
users who have multiple region data installed. (*)
(*) - the only way this UI would make sense is if it was only apparent when the
browser was run in a special mode - i.e. more than one pack present. This is
likely an edge case.
MPT, the owner of the UI Design Component and Ben Goodger, the owner of the
Mozilla UI have both objected to this. They have both stated that there should
be _no_ View menuitem. Not one. Not two. None.
Comment 28•24 years ago
|
||
Look, I've been really nice, and waited very patiently for someone to produce a
spec, or to explain why Mozilla would need to care in the slightest about which
region a user is in, or even to explain what the smeg `regional content' *is*.
I've been operating under the assumption that `regional content' is a set of
default bookmarks and sidebar panels, and that the premise of this UI is that
users are somehow going to be appreciate their own selection of bookmarks and
sidebar panels being obliterated in exchange for mozilla.org's selection of
bookmarks and sidebar panels devoted to a given `region'. I would love to be
proven wrong on this point, because then this RFE (it's not a blocker, it's an
RFE) would make a whole lot more sense.
But all I've gotten so far is handwaving about `addressing' back-end changes,
and dodgy comparisons with the `Apply Theme' menu item (which shouldn't exist
either).
> I would say that changing the UI language could be something that would be as
> frequent as changing the profile, as in the case where 2 people sharing a
> computer are fluent in two different languages.
So, why not make UI language part of the profile, so that people don't have to
change two different things when switching profiles? And if that is the case
already, why do you need separate UI for it elsewhere? If this is just for
convenience of i18n debugging, surely it should go in the `Debug' menu instead?
> I would just add that another browser out there forces the user to click
> through 3 windows (internet options>languages>change) before the UI language
> can be changed. This can be quite cumbersome
Well of course it is. It's a basic UI principle that items on the top of the
list of things you do most often should be easy to get at, while things which
are 7043 and 7044 on that list should be harder to get at. Should we have an
item in the `View' menu for `Anonymous FTP Mode', too, just because another
browser forces you to click through three windows to get to that?
Please, someone explain exactly what this feature does, who it is intended for,
how it would improve usability overall, and how it is better than alternative
UIs for the same function (e.g. controls in the profile manager, or in the
prefs dialog). Otherwise, I really don't think this UI is in a fit state to
enter the Mozilla tree.
This is absurd.
(I am commenting this as a Mozilla bug, since the this is Bugzilla. The way this
is handled in Netscape is none of my business.)
* Setting the UI language most certainly does not belong in the View menu,
because
- The View menu is supposed to contain frequently accessed items and (just
like monolingual English-reading Americans) "international users" don't
switch the UI language all the time. It is a one-time choice. (I guess
from the American point of view, I am one of those strange "international
users" with special needs, because I don't live in the U.S. and I am able
to read more than one language. Despite all that, I don't feel any kind
of need to quickly change the UI language every once in a while.)
- In multilingual families, there is normally one common language that all
the family members understand at least somewhat. One could argue that the
common language might be only spoken and some of the family members
couldn't read the language. Even that doesn't warrant cluttering the View
menu for everyone, because the family can use the profile feature of
Mozilla or the multiuser services provided by the OS.
* Regional content selections shouldn't be in the View menu in Mozilla,
because Mozilla shouldn't come with any regional content.
- The official attitude is that Mozilla isn't for end users. (I might not
agree with that, but I'll use the common assertion for the purpose of
this bullet point.) The people who use Mozilla are quite capable of
choosing their bookmarks themselves.
- mozilla.org is coordinating the development of a Web browser. Providing
pointers to content is not mozilla.org's business. Due to the point
above, providing default bookmarks is virtually of no value. However,
what bookmarks get included and what not, has the potential of being a
very controversial issue. When the audience doesn't really need default
bookmarks, there is no point in including default bookmarks and then
having to deal with the complaints.
- Even if mozilla.org chooses to include the framework for providing region-
specific bookmarks for the convenience of other parties building Mozilla-
based products, the UI of Mozilla shouldn't be cluttered in the process--
especially, because even users who travel a lot aren't likely to switch
the region pack when they can just access some local portal without making
the region pack of their home region disappear.
(Yes, I have noticed, there is already a submenu in the View menu, but the fact
that the submenu somehow got there doesn't mean it is a good thing that it is
there.)
Reporter | ||
Comment 30•24 years ago
|
||
Reporter | ||
Comment 31•24 years ago
|
||
MPT ~ Pls see the attached spec that was prepared by German. Note that it
addresses changes to the UI, not only from the menu items, but also from the
Prefs dialogue and Profile Manager. IF we can't agree on the View menu items, I
do think we are definitely in agreement on the need for the change in Profile
Manager, and that the user probably should have the ability to change Language
UI and content from within prefs.
Reporter | ||
Comment 32•24 years ago
|
||
Pls review the attached design spec, and lemme know your thoughts.
As we have discovered when defining the feature, and utility for the users,
there is currently no means for users to recieve addtional packs outside a menu
item link from the View Menu (i.e. A x-platform download function in prefs is
not supported by the Mac OS). Hence, the need for a Themes "Download More" link
form the View menu. Without the ability to download addtional UI packs, the
feature is of little use to users who start with the available languages, and
wish to use the native language, when the pack is made available.
One of the greatest benefits of the Language UI packs, is that a user in China,
who currently has the US release, can download Tradiotnal or Simplified Chinese
when the pack is made available (i.e. Mozilla users will not have to download
and install a full build to use the product in their language). This equates to
a 7+ MB download vs. 400K for the Language UI.
Is there another way to "Download More" packs or themes other than a menu link?
The proposed spec (images missing, BTW) says about the content pack: "like
themes will be multiple per profile, expected to get changed more frequently
then themes"
Why would there be multiple themes per profile? Why would regional content pack
be changed more frequently than themes? Why would regional content packs be a
feature of Mozilla (and not only a feature of Netscape 6.x due to marketing
requirements)?
>there is currently no means for users to recieve addtional packs outside
>a menu item link from the View Menu
Can't langpacks be downloaded like any other files from www.mozilla.org?
>Hence, the need for a Themes "Download More" link form the View menu.
Why the View menu? The View menu is not a place for links. The Bookmarks menu is.
Reporter | ||
Comment 34•24 years ago
|
||
From UE perspective, it would be nice if customizations worked in a simlar
fashion, so that users don't have to relearn behavior. In short, we need an easy
way for users to get to the download page for packs, much like themes.
Comment 35•24 years ago
|
||
I (as an L10n contributor) agree that the view menu isn't really the correct
place for UI language (and of course not for region) settings, it should be
prefs, including the "download more" thingy (yes, I heard wht you told about Mac
but I'm speaking from the view of "what would be correct").
Additionally, I think it's good to have it in profile creation, as it currently
_is_ a per-profile setting (addressing mpt here).
Region packs currently include lots of URLs in Mozilla UI, which could be
different in different regions where Mozilla is used (default home page, page of
release notes, URL to call on throbber click etc.). I don't remember any real
language content in region pack currently.
Note that we already have these parts of UI (at profile creation and in "View"
menu, not in prefs) for language content.
> From UE perspective, it would be nice if customizations worked in a simlar
> fashion, so that users don't have to relearn behavior. In short, we need an easy
> way for users to get to the download page for packs, much like themes.
So now the theme switcher is used as pretext for adding more settings of the
permanent nature to the View menu. :-( The theme switcher is in the View menu
mainly to show off the feature. See bug 43546.
Comment 37•24 years ago
|
||
The Netscape UI spec for this feature is published at
http://www.mozilla.org/projects/ui/communicator/framework/langcontentui/
Now that I see the images of the spec, I think "region" is a misnomer. Where
would the contents of the "region" pack be displayed?
Reporter | ||
Comment 39•24 years ago
|
||
I would propose that all Content Packs be under one item, including "region".
Open to suggestions though.
Q? - It sounds to me, that we may have agreement that Language UI and Content
Packs setup should be available from Profile Manager and Prefs. The one
contentious area is the menu items under View. Is this correct?
Comment 40•24 years ago
|
||
Comments on the UI spec:
- Instead of a cascading menu entry "Apply Content Pack >", why don't we
just have a "Apply Content Pack..." which opens the pref dialog to
Content Pack panel? If we do this, maybe the menu entry should be under
the Edit (not View) menu similar to "Preferences..." (The same suggestions
apply to "Apply Theme >".)
- In the pref dialog panel, why does the apply button need to include the
name of the content pack (e.g., "Apply San Diego Regional")? Since the
pack is already highlighted, it seems "Apply" is sufficient. And if the
content pack has a really long name, then we'll end up with a really wide
button. Addtionally, any time you piece together phrases, you create
localization problems because word ordering is language dependent.
Comment 41•24 years ago
|
||
> Now that I see the images of the spec, I think "region" is a misnomer.
I agree. What has really been separated is UI v. content (not language v.
region). Both UI and content may be language and/or regional dependent.
Someone may want English UI for British or American regions (e.g., "-or" v.
"-our", "-ize" v. "-ise"), or Swiss content in the French or German language.
Comment 42•24 years ago
|
||
sounds like we're still talking about the design of this feature, i.e. we stil
haven't agreed on whether this is the right thing to do for mozilla. I don't
think my team can fix this. i18n group will have to find some other resources or
make it netscape only. I'm moving this bug to Future.
Target Milestone: mozilla0.9.1 → Future
Comment 43•24 years ago
|
||
Thankyou for posting that document, German. I wouldn't call it a `spec', since
it doesn't answer any of the basic questions I think a spec should cover (what
the feature *does*, who would use it, why they would use it, why alternative
designs were rejected, etc); but those questions have been answered to some
extent by others in this bug.
It's now quite clear that there a `Set Language' item in the `View' menu would
be more confusing and cluttersome than useful, since Mozilla users do not need
to change their UI language nearly often enough for the feature to deserve a
menu item. UI for this in the profile manager (bug 65253) would be quite
sufficient. And for downloading new language packs, every Mozilla user should
be able to do that on the same page on mozilla.org from which they downloaded
Mozilla in the first place -- or via a default bookmark pointing to the
download page, for those users who have installed Mozilla as part of their
Debian, Red Hat, or other GNU/Linux distribution.
As for `content packs', they may be of use to users of Netscape's commercial
distribution, though obviously you've still got a long way to go before you
come up with a UI which is close to being understandable. (From German's
mockup: `Friendly explanatory text that goes to great effort to explain what a
content packs is' ... I think that sums up the problem quite nicely.) But as
Henri so thoroughly pointed out, content packs are of no use to users of
Mozilla, who are quite capable of setting up their own bookmarks themselves,
and who indeed may be queasy about mozilla.org offering default bookmarks at
all. Nor, I think it's fair to say, would they be of use to the vast majority
of Mozilla distributors, most of whom will be too small to have the resources
to organize multiple content packs for different regions.
Therefore, as owner of the `User Interface Design' component where this bug
currently sits, I'm moving this bug to the `Derivatives' > `Netscape 6'
component. I'd like to thank those people at Netscape who worked on the back
end to separate language settings from content settings; this means that
language settings (which are useful for Mozilla users) can be part of the
Mozilla code, while content settings (which are not useful for Mozilla users)
can be made Netscape-only.
Moving to `Netscape 6' component. Any appearance of `content packs', or any
introduction of language-/region-related items in the `View' menu, in the
Mozilla trunk will be treated as a usability regression.
Assignee: vishy → lchiang
Component: User Interface Design → Netscape 6
Product: Browser → Derivatives
QA Contact: zach → lchiang
Target Milestone: Future → ---
Version: other → unspecified
Comment 44•24 years ago
|
||
> content packs are of no use to users of
> Mozilla, who are quite capable of setting up their own bookmarks themselves,
> and who indeed may be queasy about mozilla.org offering default bookmarks at
> all.
Mozilla already includes bookmarks under "Personal Toolbar Folder" and
"Mozilla Project". It is useful and productive to provide a standard set of
bookmarks to facilitate project testing and feedback as well as providing
overall project info.
Additionally Mozilla adds/configures:
- Tinderbox sidebar entries
- URLs under the Help, Debug and QA menus
- search engines
- home page
A given Mozilla project or a group of developers may want different content.
For example, I believe the Mozilla Japan folks have their own bug system
which they use to log bugs using Japanese.
Groups of developers working on Mozilla ports or derivatives may want a
different Tinderbox in the sidebar, or a different bug/feedback form, or
different Debug/QA tools.
The notion of "content packs" is valuable to Mozilla as well as for commercial
usage. Whether or not anything should be exposed in the View menu is a
separate issue.
Comment 45•24 years ago
|
||
bobj - please tell me if you want me to move this bug to Bugscape. Thanks. It
is not going to do well on my plate.
Comment 46•24 years ago
|
||
lchiang> bobj - please tell me if you want me to move this bug to Bugscape.
lchiang> Thanks. It is not going to do well on my plate.
Note German's UI spec removes UI switching from the menu and makes it
only available via prefs of profile manager, so I updated the summary from
from
"View" menu: Need to add "Set Language" and "Set Region"
to
"View" menu: Add "Apply Content Pack"
For now, reassigned to jaimejr. If we agree to a fix, I'll find a real owner.
My 2 cents (or am I up to 8 cents now):
I don't believe this is an issue of a Mozilla v. Netscape feature. This
should be WONTFIX or remain open in bugzilla (under Browser not Derivatives).
I believe content packs are useful (see previous comment), and the issue is
whether it belongs in a top level menu or only accessible in prefs and the
profile manager. (If this gets marked WONTFIX, and Netscape still wants
the menu entry, then a new bug should be opened in bugscape.)
I agree in principle that menu entries should be reserved for frequently
used operations.
On the other hand, this principle does not seem to be evenly applied to our
current menus. We seem to also include things there that we think are useful,
but not easily discoverable (e.g., View|Apply Theme, View|Use Stylesheet,
View|My Sidebar Search Tab|Basic/Advanced) Practically, I think
"Apply Content" could more useful than "Apply Theme" for most users.
I think we need to hear mpt's response to my comments.
Assignee: lchiang → jaimejr
Summary: "View" menu: Need to add "Set Language" and "Set Region" → "View" menu: Add "Apply Content Pack"
Reporter | ||
Comment 47•24 years ago
|
||
I would priotize dealing with releated Profile Manager and Prefs bug, first.
I 100% in agreement with Bob's comments, and I am even willing to agree on not
having menu items under view. WFM, if . . . However, I still beliew all browser
customizations, such as View | Apply Theme, should be consistent in their
behavior. And, still have the requirement for an easy, and consistent way (ala
Themes) to download addtional packs.
We should not have one-offs for a user to download and customize the browser.
Summary: "View" menu: Add "Apply Content Pack" → View" menu: Add "Apply Content Pack
Comment 48•24 years ago
|
||
> Practically, I think "Apply Content" could more useful than "Apply Theme" for
> most users.
As I said in my 2001-05-15 comment, and Henri suggested in his 2001-05-15
comment, you shouldn't use the uselessness of `Apply Theme' as a precedent for
including the (arguably) slightly less useless `Apply Content Pack'. `Apply
Theme' shouldn't be in the menus either.
> Mozilla already includes bookmarks under "Personal Toolbar Folder" and
> "Mozilla Project". It is useful and productive to provide a standard set of
> bookmarks to facilitate project testing and feedback as well as providing
> overall project info.
That is not a feature, it is a bug. It is a temporary workaround for the
appalling state of the mozilla.org Web site -- such that you can't find these
links (and bookmark the ones *you* are interested in) within a few clicks from
the default home page. Once the mozilla.org site is fixed, I expect the number
of default bookmarks in Mozilla to approach zero.
> The notion of "content packs" is valuable to Mozilla as well as for
> commercial usage.
It looks as if you're trying to invent uses for content packs after the fact.
All the examples you gave are of single links or panels -- there is no obvious
group which would have a large intersection in a large number of bookmarks
and/or sidebar panels they would be interested in, such that it would be more
intuitive for those people to switch to these bookmarks or sidebar panels as a
set rather than adding the individual bookmarks or panels which they are
interested in. I strongly suspect the same will be true for Netscape users,
too; but that's a problem for Netscape to deal with.
Reporter | ||
Comment 49•24 years ago
|
||
Per Vishy's request, setting priority P1, so that we can triage with Nav for
M0.9.2.
Marking as RTM, and nsCatFood.
Comment 50•24 years ago
|
||
adding URL to German's spec
Reporter | ||
Comment 51•24 years ago
|
||
Build ID: 2001060409
This is happening on a German Build with the Build ID: 2001060409. It occurs
when I submit a Form (ex. Submitting comments in Bugscape by cliking on the
"Commit" button or keying enter.
Reporter | ||
Comment 52•23 years ago
|
||
oooooops . . . pls ignore my last statement. This was meant for another bug. :-(
Reporter | ||
Comment 53•23 years ago
|
||
Adding PDT+ per the Friday afternoon PDT meeting.
Whiteboard: PDT+
Comment 54•23 years ago
|
||
Jaime, are you going to reassign this?
Reporter | ||
Comment 55•23 years ago
|
||
Reassigning to Ftang. Suggest we use the single menu item (View | Set
Language/Region), change the word Word "Region" to "Content", so it matches the
Prefs implementation for this feature. Addtionally, the new drop-down, should
look as follows . . .
Download More
<------------>
Apply Language
> US English
> French
> (build, to accept download packs)
<------------>
Apply Content
> United States Region
> France Region
> (build, to accept download packs)
Assignee: jaimejr → ftang
Reporter | ||
Comment 56•23 years ago
|
||
Adding rudman and hangas to cc: list. Any ideas here guys?
Reporter | ||
Updated•23 years ago
|
Comment 57•23 years ago
|
||
Well my idea is to not even have these menu items and just support these features
from the prefs. It seems to me that the number of users that would need to
change these settings every day are very few. Adding a menu item to make a
feature more discoverable is not in my opinion a good idea. Too many menu items
make every menu item less discoverable. I think we have too many menu items in
mozilla already.
Maybe in the future there can be a way to turn on features like this for folks
that do need to change these settings every day, for now I think we should target
the majority of our users.
Reporter | ||
Comment 58•23 years ago
|
||
Hangas - I would agree with your statements on moving this stuff to Prefs. In
fact, the ability to switch the packs in Prefs is already available. However, we
are not allowed to put a "Download" button in Prefs because we can't have
multiple Modals dialogues up at one time. Hence, the need for the menu item as
it is, to support the Download of more packs. Addtionally, it is consitent with
6.0 behavior. Any other ideas?
Comment 59•23 years ago
|
||
So are you saying that because one menu item is needed that all of them need to
be there?
Reporter | ||
Comment 60•23 years ago
|
||
Actually, I'm looking for suggestions right now. It would be nice to be
consistent with how Theme customization works, and for language switching might
actually be userd more. Any ideas?
Default bookmarks perhaps?
Comment 62•23 years ago
|
||
Jaime, what about instead of three menu items (or correctly submenus) about
locale, content pack and theme if we change it to one menu item (submenu) called
"Download UI" (or similar) with Items for "New UI Language", "New Content Pack"
and "New Theme"?
This would decrease menu items in view menu (which is the most overloaded one
already), keep the download feature and get rid of chrome switching from the
menu. This should and can be done via prefs (existing profile) or profile
manager (locale/content for new profile).
Comment 63•23 years ago
|
||
No objection to Robert Kaiser's idea.
I don't think I should own the UI work.
Comment 64•23 years ago
|
||
I object, View>Download>Foopy makes no sense to me. If you're going to change
its functionality then I suggest you try to find a correct place to stick this
nightmare.
Help>Software Updates used to exist, and can probably be resurrected. We could
put it there.
Reporter | ||
Comment 65•23 years ago
|
||
I prefer Robert Kaiser's idea, since it concentrates all UI Customizations under
one umbrella for consistent usability. Addtionally, there is "NO" HELP |
Download menu item now, and I much rather consolidate items into logical
system, then create new ones.
Vishy - FTang does not feel he should own this one, and we are come up to M0.9.2
deadline, or part it. I'd be agreeable to removing the seprator, and just having
the Download More option for this round. In hopes, that we can improve usability
in M0.9.3 or just a little bit later. My immediate need right now is provide
users with the ability to download MORE packs. What do you think?
Comment 66•23 years ago
|
||
Jaime - We already have Download More in the UI today. Are you saying that that
is sufficient? Sorry - I could not understand all the comments in the bug.
Reporter | ||
Comment 67•23 years ago
|
||
All I am saying, is that it could work for that way for M0.9.2, but we need to
work on suability for M0.9.3 and later (i.e. Keep "Download More", remove
everything else for this round). Just a suggestion, so we can move on . . .
Comment 68•23 years ago
|
||
I sure hope we track how many downloads we get of content packs in 6.1, so we
can prove that this isn't needed, and it can be taken out. This is an excellent
example of bloat at it's finest.
Reporter | ||
Comment 69•23 years ago
|
||
here's a suggestion via mike kaply by way of timeless . . .
------- Additional Comments From timeless@mac.com 2001-06-06 12:10 -------
Henri Sivonen, did you read mkaply's comments (2001-06-05 12:31)? . . .
The fact that we can't open a web browser from the preference dialog because
it's modal is a problem. Microsoft has a solution which is to prompt the user
for permission to close the dialog and open the next window (dialog in their
case, but whatever).
I would be amaiable to this solution, if: 1) Everyone agrees this is the best
way to go, and we are done; 2) We got help with the code (timeless is this
something you can do?); 3) Recieved expedient reviews and the check in occurs
ASAP.
Vishy/Ftang - Any addtional thoughts? I think this would be solution, IF it is
doable. Alternatively, I would default to my other proposals.
Comment 70•23 years ago
|
||
I like this solution that timeless suggests. We could use that for other buttons
inside of prefs as well. Do you have the exact wording on that dialog? I can
probably get some help to create this if needed.
Reporter | ||
Comment 71•23 years ago
|
||
HOUSTON...WE MAY HAVE A SOLUTION.
Ok, looks like we got some agreement here from the Netscape house (UI and PM),
plus a volunteer to take a look at this over the weekend (i think?).
Vishy/Ftang - Unless either of you adamantly disagree, I think Hangas and I
think this could work . . .
Comment 72•23 years ago
|
||
I like this solution - prompting the user and closing the prefs dialog, since it
is known UI design i.e. IE does it and it seems to be a reusable pattern
(Commercial could use this same pattern in the Smart Browsing panel > More
Information button which brings up a web page and causes some weird behaviour).
Lets not get our expectations unrealistic about
- having the code in a hurry (to do this before 6/26 requires drivers approval
as drivers controls the branch until next week at least and this is unlikely to
get deemed "critical for m0.9.2").
- expedient reviews.
This will have to go through normal review and super-review process and the
turnaround can be non-predictable sometimes.
However - for Netscape purposes we will need a L10N exception to do this if it
is not in the tree by 6/26 (at least the strings) so it would be good to start
on this. I'll email mcarlson about the exception.
Reporter | ||
Comment 73•23 years ago
|
||
Thanks Vishy! Do you or anyone know, a way we could get an expedient "ok to
proceed" from drivers (e.g. I am assuming drivers are the same people reviewing
. . . lemme know if this is not the case). It sounds like a lot of people
commenting int the bug like this solution in both the Mozilla community, and
Netscape. I would think this would be something we'd like to do ASAP to resolve
this one and move on to other things.
Comment 74•23 years ago
|
||
Jaime - none that I'm aware of. I think drivers will want to see the patch and
I've not heard of drivers pre-approval. The question will also arise about the
relevance of this patch to mozilla for mozilla0.9.2. The best bet is to work on
implementation, then r,sr then assess where we are. We may already be branched
by then and not need drivers approval if m0.9.2 is out the door.
Reporter | ||
Comment 75•23 years ago
|
||
Vishy - OK, I think there is a Mozilla contributor working on this one, but not
100% sure. And, I don't think Ftang wants to get into this one. Any ideas on how
to get the patch work done? IS this something we need for other modals in the
Prefs panel? I don't manage a dev team, so I am leaving this one to you, Bobj
and Ftang to resolve, if we don not get external help.
Comment 76•23 years ago
|
||
Reassigning to vishy; vishy, do you know who is working on this bug? It seems
that we need to get it at least on a limbo build if we cannot make it by 6/26.
Please, update the bug with comments on when it can be done.
Assignee: ftang → vishy
Updated•23 years ago
|
Component: Netscape 6 → Preferences
Product: Derivatives → Browser
Target Milestone: --- → mozilla0.9.3
Version: unspecified → other
Comment 77•23 years ago
|
||
Ben - could you take this. the summary is inaccurate, can you read the bug and
update the summary to the right value. we shd target this to the first limbo
build (by the end of this week.
Assignee: vishy → ben
Comment 78•23 years ago
|
||
Ben, , this is PDT+ bug. Tomorrow, on Tuesday, we'll try to build the first RTM
candidate. It would be good, if this could be resolved ASAP.
Comment 79•23 years ago
|
||
Ben - could we get a patch in for this on Thursday since it would be good to
have the Friday build be the first candidate. thanks, Vishy
Comment 80•23 years ago
|
||
Comment 81•23 years ago
|
||
matt says 'r=matt' and blake says 'sr=blake'
they both express general disappointment in the modal change, but I think it's
peachy keen!
Comment 82•23 years ago
|
||
msanz -
this involves adding another string. is this ok
Comment 83•23 years ago
|
||
Ben - it is okay for this string change as it is a PDT+ bug. Please check this
into the mozilla trunk and branch today. Please send an email to msanz with
the bug number, mentioning the l10n impact. thanks! Vishy
Comment 84•23 years ago
|
||
we should get this baby into the branch if it's ready.
Comment 85•23 years ago
|
||
Jatin, fyi, for possible doc impact.
Comment 86•23 years ago
|
||
Ben:
Your last patch (resources/content/pref-contentpacks.xul,etc) looks more like
patches for bug 65251:'Need to add "Language" and "Regional Content" to
Appearance in Preferences...'
Comment 87•23 years ago
|
||
Ben,
Will your patch for this bug add "Download More" and "Apply" buttons to the
Content Packs panel in Prefs? Also, I see in the 07-05-06-trunk build that the
title for this panel is blank; will the patch fix that as well? I will attach a
screenshot in case it is unclear what I'm referring to.
Comment 88•23 years ago
|
||
Comment 89•23 years ago
|
||
yes, we need the feature in. Please check in asap, preferably before 7/6
Comment 90•23 years ago
|
||
Button checked in. Marking FIXED.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 91•23 years ago
|
||
Docs - please note that this makes the pref panel be non-modal now.
Comment 92•23 years ago
|
||
Switching QA contact to jonrubin for bug verification.
QA Contact: andreasb → jonrubin
Comment 93•23 years ago
|
||
Reopening - Did not see "Apply Content Pack" in View menu on 07-06-06-trunk
(tested on WinMe-Ja).
Ben: Could you please answer my question from 07/05 about whether your patch
will apply to the Prefs UI as well? Thanks.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 94•23 years ago
|
||
I think the Summary was misleading. After discussion the summary of the bug is
"add Content Pack panel to preferences, with a download more button". That is
what is checked in.
Summary: View" menu: Add "Apply Content Pack → Prefs: add Content pack panel with Download button.
Comment 95•23 years ago
|
||
marking fixed per new summary. please verify. oh wait - you will have to wait
till the preferences smoketest blocker is cleared.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Comment 96•23 years ago
|
||
i've verified bug 89600 as fixed.
some observations:
on linux [2001.07.06.12-branch comm], the category tree has a blank space for
Content Packs, and the button in the panel is blank.
on mac [2001.07.06.12-branch comm], Content Packs isn't in the prefs dialog at
all.
unable to currently check win98, as i'm booted up in linux [could someone else
pls check?].
interestingly, linux trunk mozilla build from 20:15ish last night, Content Packs
*is* listed in the category tree. [no button in panel, but that's a recently
added feature, eh?]
Comment 97•23 years ago
|
||
see bug 89725 for a patch that fixes the blank menuitem in prefs & the blank
button. the patch will need to be applied to both the trunk & branch.
Comment 98•23 years ago
|
||
My observations are the same as Sairuh, except on Linux. I tested branch and
trunk builds on Win32, Linux, and Mac as follows (on each platform, trunk
results matched branch results):
WinMe-Ja, 2001-07-07-12-0.9.2 comm and 2001-07-08-10-trunk comm:
Content Packs panel does appear, and Download More works. However, choosing the
new region in the "Installed content packs" window does not result in the
"Restart NS6" message after clicking OK (the message does still appear if
selecting the region via the View menu). The region does change correctly if
the browser is restarted.
Linux Redhat 7.1-Ja, 2001-07-08-04-0.9.2 comm and 2001-07-08-06-trunk comm:
Same results as above on WinMe-Ja.
MacOS9.1, 2001-07-08-03-0.9.2 comm and 2001-07-07-08-trunk comm:
Same results as Sairuh: Content Packs panel does not appear in Prefs.
Reopening this bug for the problem on Mac.
Jaime, could you please confirm that the fix as verified on Win and Linux is
sufficient without the "Apply" button? Thanks.
Status: RESOLVED → REOPENED
OS: other → All
Hardware: PC → All
Resolution: FIXED → ---
Comment 99•23 years ago
|
||
Jaime, please note that you originally filed this bug to add "Apply Content
Pack" to the View menu. With the new summary added on 07/06, it is now
essentially a dupe of bug 65251.
Comment 100•23 years ago
|
||
From various comments in this bug (mpt and others), I'm missing one important
thing in the fixes to this bug: I thought it was agreed that the view menu items
for "Languages and Web Content" as well as "Apply Theme" should go away.
At least the first of those two should be addressed here, the second may get a
different bug and resolved on its own way - but it should bet away as well!
This will also make other bugs e.g. bug 66909 obsolete...
Updated•23 years ago
|
Whiteboard: PDT+ → PDT+, reopened
Comment 101•23 years ago
|
||
Please open the remaining issues with this bug as new bugs (its way too
confusing to wade through this long discussion). Also we need to assess the PDT+
nature of the new bugs not just inherit that into the remaining issues with this
bug.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 102•23 years ago
|
||
Vishy - 65251 was the bug dealing with Prefs issues for the packs. This bug was
opened to deal the View | Menu. Now that the Prefs dialogue seem to support
Download, I would be amiable to close this one, and reopen the bug to hide/move
(debug) this menu item; so long as Prefs functions correctly and supports all
platforms.
At a minimum, View | Set Language/Region is no longer applicable, since we call
the packs "Language" and "Region" packs.
Comment 103•23 years ago
|
||
Now that the functionality requested (ability to download more content packs
from preferences dialog) is present, can someone verify this bug fixed?
Comment 104•23 years ago
|
||
This functionality has already been verified on Win and Linux; it cannot be
verified on Mac because the Content Packs panel was not found in Prefs.
Reporter | ||
Comment 105•23 years ago
|
||
Need to Reopen. This has not been fixed in Mac.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 106•23 years ago
|
||
It turns out that fixing bug 90002 will not fix this on the Mac (the patch in
90002 was already on the branch). There is something deeper going on here - I'll
have to talk to Pchen tomorrow to track it down.
Assignee: ben → vishy
Status: REOPENED → NEW
Whiteboard: PDT+, reopened → PDT+, reopened eta=07/11.
Assignee | ||
Comment 107•23 years ago
|
||
Taking from Vishy since we've fixed this on my powerbook.
Assignee: vishy → pchen
Assignee | ||
Comment 108•23 years ago
|
||
Assignee | ||
Comment 109•23 years ago
|
||
As is usual for stuff not showing up only on the mac, need to add mozilla/
extensions/content-packs/resources/jar.mn to the mac build list
Comment 110•23 years ago
|
||
r=vishy (I saw this working). Blake could you sr= this?
Whiteboard: PDT+, reopened eta=07/11. → PDT+, has patch, r needs sreta=07/10.
Comment 112•23 years ago
|
||
Hold on, oops.
sr=ben@netscape.com for the branch ONLY.
This line is un-necessary for the trunk given the same line several lines up.
The reason this wasn't getting built was that I forgot to set content_packs to 1
in MozillaBuildFlags.txt when initially checking this in. This is the correct
fix for the trunk as it allows people to disable this UI. A patch to do this is
attached to 65251 and is what should land on the trunk, I think.
Assignee | ||
Comment 113•23 years ago
|
||
Assignee | ||
Comment 114•23 years ago
|
||
Just IM'd with Ben some, and we agree that the fix he attached to 65251 is the
correct way to fix this.
Whiteboard: PDT+, has patch, r needs sreta=07/10. → PDT+, has patch, eta=07/10.
Assignee | ||
Comment 115•23 years ago
|
||
I've just checked in on the branch. I leave it up to Ben to check in on the
trunk. Marking this bug fixed.
Assignee | ||
Comment 116•23 years ago
|
||
Umm, no, really, marking FIXED. ;-) Sorry for the spam
Status: NEW → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Comment 117•23 years ago
|
||
As I didn't see anyone mention a seperate bug about removing the menu items from
"View" menu, i filed bug 90304 for this problem.
Comment 118•23 years ago
|
||
Reopening - Still cannot see Content Packs panel on Mac trunk build as of
07-12-08-trunk-comm.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 119•23 years ago
|
||
I think we're saying that the branch build is fine but the trunk build is
broken. REmoving PDT+ designation in that case. Ben/paul - please fix the trunk
build when possible,
Whiteboard: PDT+, has patch, eta=07/10. → fixed on branch, broken on trunk
Comment 120•23 years ago
|
||
Vishy, sorry if my earlier comments were not clear. Yes, you are correct--the
Mac branch build is fine now, but the trunk still doesn't show the Content Packs
panel. Just to be sure, I double-checked today's builds
(Mac comm. 2001-07-13-03-branch and Mac comm. 2001-07-13-04-trunk).
Comment 121•23 years ago
|
||
Assuming Ben intended to mark this as fixed based on fixing bug 65251.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•