Closed Bug 135250 Opened 22 years ago Closed 22 years ago

Context menu: "open link in new tab" should be below "open link in new window"

Categories

(SeaMonkey :: General, defect)

defect
Not set
major

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: jruderman, Assigned: marlon.bishop)

References

Details

(Keywords: regression, Whiteboard: [adt2 RTM],custrtm-,[fixed on trunk])

Attachments

(1 file, 1 obsolete file)

"Open link in new tab" is the first item on the link context menu.  It should be
just below "open link in new window", or hidden until the user selects "tabbed
browsing mode" in prefs.
Keywords: regression
*** Bug 135257 has been marked as a duplicate of this bug. ***
OS: Windows 98 → All
Hardware: PC → All
How about this: If "Open tabs instead of windows for middle-click or
control-click of links in a Web page" is turned on in prefs, Open In New Tab is
at the top, otherwise Open In New Window is at the top.
Finally found this bug after looking for 15 minutes. Updating summary to make it
easier to find by having both new window and new tab. I'd just as soon have
either a tab mode or a window mode, so like the reporter I'd suggest hiding the
tab item until tab-click is turned on. I never use tabs and don't intend to. I
don't see the point of having both in the context menus--it just slows me down.
What's the point of picking each time? Are there really people that use both? In
any case, the default behavior is new windows, so it should be the top context
menu option.
Summary: "open link in new tab" is first on context menu → Context menu: "open link in new tab" should be below "open link in new window"
Keywords: mozilla1.0, nsbeta1
There are quite many people who use both.  But yes, the top option should
imo be the default one.  Which is "open link normally", not either of
these two.
I think the order needs to be based on user preference in some fashion (as per
comment #2), otherwise there will always be some group disagreeing with its
current status (and filing / reopening bugs).

Boris: I think that "Open Link Normally" may be confusing to people, whereas
"Windows" and "Tabs" are less so.  Actually, to be honest, it's confusing to me.
 Isn't opening a link normally the same thing as a left-click which, as far as I
know, is always loading the page in the current window?  And, if so, why
wouldn't you just left-click in the first place to achieve this?
I think the phrase you're looking for is "Open New Whatever".


:)
in the spec, [Open Link in New Tab] is above because it was felt that a) it should be on by default to better promote the feature's value 
and increase its discoverability; and, b) because we want to emphasize tab use over window use.  * Not * meant to replace window use, 
but merely to accompany it, as a higher or equal frequency alternative to windows.  I am willing to bank on the majority of tab users will be 
'combo' users - making use of tabs when it makes sense, and making use of windows when it makes sense.   We are still open to suggestions 
on this, but hopefully more insightful than, "i like windows better than tabs" (or vice versa).  either way it's not an easy call, but i feel that 
by promoting tab browsing in this way, we're showing off our advantages over tabless browsers such as IE. 

[Open Link] is the default item, and should be the topmost item (as indicated in spec)
> Isn't opening a link normally the same thing as a left-click which, as far as I
> know, is always loading the page in the current window?  And, if so, why
> wouldn't you just left-click in the first place to achieve this?

'open link normally' was a description of the item, not suggested text.  The
text would be [Open Link] as Marlon says or maybe even just [Open]

On Windows it is the convention that default action performed on left-click
should be in the context menu, the first item, bolded, and separated from the
rest of the context menu by a separator.  On Mac it is a necessity that the
default action performed on left-click appear under the cursor when the context
menu pops up on click-hold (that way click-quickly and
click-slowly-which-triggers-context-menu do the same thing).

On linux there is no convention (surprise).
"Open Link" and just "Open" are no good -- neither has any implication of new
anything, window or tab, so the assumption would be that they would open
something  (what?) in the current window/tab.
> we want to emphasize tab use over window use
I'm interested in understanding the reasoning here. And if this is the case, why
didn't the File-New submenu change to have Navigator Tab first as well? Tabs
have not had the same UI and testing focus as new windows and have a slew of
bugs related to them. Emphasizing tab use is a poor decision if you ask me. UI
should not be designed around showing off new product features.

> I am willing to bank on the majority of tab users will be 
> 'combo' users - making use of tabs when it makes sense, and making use
> of windows when it makes sense.

How exactly would a user determine which "makes sense"? Randomly? I don't want
to make this choice every time.

Even in the combo-user case, it seems fairly clear that users will have a
preference for their typical choice. It would make a great deal of sense to me
to have menus reflect that preference. The closest pref we have now is the
middle-click tabbed browsing option. If it's set (or create a more obvious pref)
put Open New Tab first. If not, put it second.

Boris and Marlon, Open Link as the first context menu item is bug 64749. Let's
not rehash it here.
Tim, i think you've mistakenly assumed that tab users are exclusively tab users
and vice versa for windows. this is not the case. the scenarios for tab browsing
 were addressed such that tabs fit within the windowing paradigm seemlessly.  so
it would be more accurate to say there are: combo-users or exclusive
windows-users.  the case for combo-users is more closely identified with the
model for the contextual menu user, which explains its emphasis there. My goal
is to follow suit in the main menus, however, main menus are a pretty touchy
subject right now. however i am pushing on that one. 
IMO the order of "new tab" and "new window" should be the same in the context
menu as it is in the main menu (under file -> new).
Using the context menu for opening links creates an automatism that's broken
whenever you use the menu for opening a new window|tab.
I think everybody's pretty much in agreement that the New Window/Tab order
should be the same in both the main menu and the context menu.  As Marlon says
in comment 11, he's trying to get the main menu order to change to come in line
with the context menu order.  (Then at least they'd be the same, even if the
order itself is in dispute.)

Personally, I think that the order in both should be controlled by the tab
browsing pref as mentioned, but the main point is that they should be in the
same order, regardless of what that is.
> On Windows it is the convention that default action performed on left-click
> should be in the context menu, the first item, bolded, and separated from the
> rest of the context menu by a separator.

Incorrect. The convention is that if the default action is in the context menu,
it is bolded. Not necessarily the first item, not necessarily with a separator
below it, not even necessarily in the context menu.

In RFC speak:
The default action MAY be included in the context menu. If it is, it MAY be the
first item, it MAY have a separator under it, and it MUST be bolded.
for reference to those of you searching the windows UI for a case where the 
default action is not the first item, isn't set off on both sides by 
seperators, but is bolded, (w2k) start>settings>network connections>{context 
menu for}any connected connection.

what you'll get is something like:

Disable/Disconnect
Status (bold)
-
Create Shortcut
Delete
Rename
-
Properties
Sort by Name

If you're in a file explorer, sort by name won't be there.
if you do it in the tray, you only get:

Disable
Status (bold)
-
Open Network and Dial-up Connections

Note that for a disconnected/disabled connection the first item will be the 
default as Connect/Enable.

Oh, you can also force an item other than open to be the default 
HKEY_CLASSES_ROOT\object\shell\(default) = someverbotherthanopen

In w2k, you can make a shortcut to a program default to runas by checking the 
box in properties, so if you right click it, runas will be bold and not the 
first item in the menu.

This comment composed in nc4 embedded in wordpad.
*** Bug 138490 has been marked as a duplicate of this bug. ***
*** Bug 138556 has been marked as a duplicate of this bug. ***
*** Bug 138682 has been marked as a duplicate of this bug. ***
By selecting "tabbed browsing mode" in prefs means unselecting "hide the tab bar
when only one tab open"? 

If in context menu "open link in new tab" is to be hidden if tab bar is hidden :
1) user may have no knowledge of tabbed browsing to be possible
2) I want tabbed browsing in the same way as new window, but without going to prefs
3) forcing tab bar to be visible for "open link in new tab" visible will force
page display area to be reduced _always_
4) User is not allow to choose, mozilla does it for him. (wasn't this the
Microsoft way?)
I mostly like the new menus, but this swap is *very* annoying.

I hate tabs, but now I keep opening them by mistake, making me hate them even more.

A checkbox to hide "open in new tab" would be much appreciated.
I don't understand why the first item of the context menu should be the same as
what happens when i click on a link with some button. If I open the context menu
I do that exactly because I can *not* achieve an action by simply clicking a
button. So if I've configured to open new tabs on middle click (because I do
this more frequently than opening new windows (yes I'm one of those
combo-users)), I want the "open new window" item at the top of the context menu
so that I have it right next at hand. And vice versa.

By the way, the default action in Windows (that one which is usually bolded) is
triggered by a double click, not by single click. Therefore I don't see such a
direct relation to the handling of a web browser.

Furthermore I agree with comment #10 in that usability should not be impacted
just to advertise product features. I think whoever opens a context menu will be
able to read more than the very first item. Mozilla advocates on the web do much
for advertising anyway, and tabbed browsing is one of their most striking arguments.
One more argument in favor of fixing this bug:

Placing "...new tab" above "...new window" 
breaks several years of user
motor memory.  A little right-click, a tiny jog to the right, and 
violia.

Instead, the application behaves unexpectedly: instead of the new 
window
appearing, the user sees some kind of strange and unfamiliar tab doohickey.
Combine 
this with another bug that breaks motor memory (bug 89308) and
Mozilla's usability dips toward 
zero for folks who open lots of windows.
It's not a matter of "default" so much as N4 parity and 
ingrained user
behavior.

In terms of all the controversy over which pref should do what, my 
very
own personal ideal would be to have one pref somewhere which allows the
user to say "Never 
show me tab-related UI nor open any tabs."
Keywords: 4xp
The view of pixeljockies is that the context menu order should change (to match
the main menu order, and IMO the sane order. ;-) If one of the people who's been
discussing how nice it would be to have this fixed would care to knock up a
patch (http://www.gerv.net/software/patch-maker should make this a trivial
exercise) then that would be great.

Gerv
Attached patch Patch (obsolete) — Splinter Review
This seems to work.
This patch updates the order in the 'This Frame' submenu. Assuming it works at
all.
Attachment #81796 - Attachment is obsolete: true
I was initially puzzled by the change in 1.0 RC1 too, but after one week of
using the browser, I've fully adapted and would never want to go back.

In most cases when you want to use right click->new window (e.g. when browsing a
complex news site, using a message board), opening a tab is the better choice to do.
Of all the right clicks on links I've done so far, at least 90% of them were
going to open a new tab, and not a new window.
> opening a tab is the better choice to do.

That is *highly* debatable since it depends utterly on the user wanting a tabbed
interface in the first place.  I don't.  I have good reasons for that -- which
I'll spare everyone the ranting about -- but fixing this comes down to the
simple issue of the UI working according to the "principle of least surprise,"
regardless of the desirability of tabs in the first place.  "Remove or hide tab
functionality completely" is a subject for a whole 'nother bug.

Thank you, Alex, for the speedy patching.
Anyone feel like reviewing attachment 81800 [details] [diff] [review]?

And does a patch this small need a super-review?
Comment on attachment 81800 [details] [diff] [review]
May as well cater for frames too

r=bzbarsky

This absolutely definitily needs sr.  From one of ben, blake, jag.
Attachment #81800 - Flags: review+
Alex, every patch needs super-review; except if the code is not part of the 
build.
Boris: thanks for the review. Christian: thanks for the clarification. I asked
because some bugs, e.g. bug 122108, have got checked in without an sr. Guess
they must have just slipped through the net.

Blake, can you give me an sr?
Keywords: patch
Alex: hm, that surprises me, but I suppose it was because it was only a wording
change... so review of jglick was enough...
Alex/Christian: Wording-only and comments-only changes have an auto-sr=brendan.
Jonas:
Apr 03 22:38:29 <brendan>	biesi: no auto-sr= from me for anyone
Apr 03 22:38:37 <brendan>	i give auto-sr= for wording changes to wordsmiths i trust

also, that bug was checked in without any mention of sr in the checkin comment.
<quote author="Gerv" source="bug 53764 comment 23">
Comment changes only have an auto-sr=brendan.
</quote>
Keywords: nsbeta1nsbeta1+
Whiteboard: [adt2 RTM]
>In terms of all the controversy over which pref should do what, my very
>own personal ideal would be to have one pref somewhere which allows the
>user to say "Never show me tab-related UI nor open any tabs."

Strongly seconded!
Comment on attachment 81800 [details] [diff] [review]
May as well cater for frames too

sr=jag
Attachment #81800 - Flags: superreview+
I could accept comment #2, but I don't want to be forced to have
Open in New Window above Open in New Tab with no way to change it;
new windows take longer to open, are more difficult to manage and
switch between, and are a pain in general; I definitely want Open 
in New Tab at the top.  I don't mind if that's a pref.  And I don't
care what the default is; I can change the setting without 
complaining.  But New Tab is used so much more freqently than
New Windows (25:1 or more) that it makes NO sense whatsoever
for New Window to be listed first.  

> Are there really people that use both? 

Yes, there are.

For now a _lot_ of us do, because after about 20-50 tabs 
(the number depends on your resolution and stuff) you
have to open a new window to work around a couple of 
outstanding bugs.  

Even after that stuff gets fixed, some people use separate
windows to keep distinct things distinct; for example, a
Google search for one thing in one window, with all the 
results in various tabs, and Bugzilla search for something
else in another window, with the bugs and attachments and
other related things in various tabs.  Bookmark Groups users
also find separate windows for each group convenient.  In
other bugs, there are people asking for the browser start
page (formerly "home page") to be a folder, which can contain
arbitrarily many bookmarks (each opened in a window) and
groups (each opened in a window, with one tab in that window
for each item in that group).  All of which is to say that
people use both.  

But this bug is about order, not the ability to hide 
undesired things.  You can hide things with CSS settings
(display: none), although this is not end-user-friendly,
and anyway that should be a separate bug.  

> On Windows it is the convention that default action
> performed on left-click should be in the context menu, 
> the first item, bolded, and separated from the
> rest of the context menu by a separator.  

Three observations about this:

1.  This would make it much more difficult to reach
    "open in new tab", which is a _very_ frequently
    used feature.  A definite usability loss.  

2.  It (putting "open link" on the context menu at the
    top) breaks with all existing browser conventions
    of which I am aware; Mozilla is a browser, not
    an operating system or file manager, so browser 
    conventions ought to be at least as important as
    Windows explorer.exe conventions.

3.  This bug is about the order of existing entries, 
    not about adding a lot of extra bonus entries.  
    That if anything should be filed separately,
    although I personally would consider it a strong
    WONTFIX candidate.

The fourth observation (that your statement about the
Windows UI is untrue anyway) has already been made.

> Emphasizing tab use is a poor decision if you ask me. 

It is a _substantial_ performance win.  But I think my
main concern is that people who obviously want to use
tabs (say, those who have checked the various "open new
tabs instead of new windows" prefs in the tabbed browsing 
prefs panel) should be able to easily do so.  If not 
checking the tab prefs results in new window being first, 
I can live with that, but I want a way to get new tab 
listed first.  Ctrl-clicking involves another hand,
which is inconvenient at best, and while I have a middle
button at home, I don't have one on every computer I ever
use Mozilla on, and some people don't have them at all.  

The convenience of the current placement of "Open Link in 
New Tab" is a big usability win.  I want to be able to get 
that placement.  I don't mind having to have a pref checked
to get it, but I want it.  Should I file that as a separate
bug?  

> But New Tab is used so much more freqently than
> New Windows (25:1 or more) that it makes NO sense whatsoever
> for New Window to be listed first.  

So? For me it isn't - I never use Tabs, unless I accidently hit this damn option
since it's at the top of the context menu. This is why it extremely annoys me
that this option is at the top.

This should _not_ be a pref, imho. Maybe a pref would be useful for "Never show
me Tab-related UI", but this feature doesn't deserve one.
Has this already been checked in, seeing that it has r= and sr=?
> Has this already been checked in, seeing that it has r= and sr=?

No, not yet. I'm trying to get approval from drivers to get this checked into
the 1.0 branch first.
Adding custrtm-; no impact on customization.
Whiteboard: [adt2 RTM] → [adt2 RTM],custrtm-
fixed on trunk.
Keywords: mozilla1.0.1
I didn't realise this had been checked in. I'm pessimistic about this getting in
1.0.1; drivers have rejected it from the branch once before.
Keywords: mozilla1.0
Whiteboard: [adt2 RTM],custrtm- → [adt2 RTM],custrtm-,[fixed on trunk]
I personally disagree with tabs being listed below windows, however I'm glad
that this fix was implemented; not because tabs are below windows, but because
there's finally consistency between the context menus and main menus.  (In the
future, if this is to be changed, I hope that it is changed in both places
rather than in just one or the other.)
If you use tabs frequently -- which you probably do if you use tabs at all --
you want "open in new tab" to be the middle-click action. So then, you want
"open in new window" to be the first in the right-click menu -- otherwise,
you've got one function taking up two redundant top positions.
I don't want to argue the point - but what about people who have no middle mouse
button?  Or, those who want the middle button to do something else?
> but what about people who have no middle mouse
> button?  Or, those who want the middle button to do something else?

Hold down Ctrl and click the link.
Yes, I do that.  But it means you have to use the keyboard at the same time. 
It's convenient to be able to do everything with JUST the mouse.

Okay. <sigh>  I'm not going to debate this, especially since I'm not saying
everything that hasn't been said before.
FYI, tabs really shine when used with open-in-the-background (bug 144851 which
is also WONTFIX due to a similar desire to accommodate old habits). I have found
"Open Link in New Tab" (as first context-menu-option) in conjunction with
open-in-the-background as the best combination, to the point of warranting to
break old habits. The combination makes reading a page with numerous items
easier as several tabs can be opened in advance. It takes a two passes process,
the first being to rapidly cruise over the page (or its visible area) to tab the
links of interest, but once this new habit is developed, tabs become impressive
and useful.
I didn't appreciate fully the tabs until I discovered open-in-the-background and
settled in the new habit. From such a perspective, "Open Link in New Tab" as the
first option is more efficient, although it causes surprise at the beginning.
Why is this bug marked NEW when it appears to have been checked in? Very
annoying this morning when I updated from 20020529 to 20020605. I had habituated
to a "right-click-twitch-hand-release" reflex motion that backgrounds a new tab,
and suddenly I'm popping up new windows!

It's going to take me the rest of the week to stop doing it, and from now on
I'll have to actually LOOK at the context menu. Where can I vote to ask that Tab
comes before Window in both menus?
Marking FIXED since this is fixed on trunk. Branch checkins are tracked with
keywords, not with the bug status.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Opened bug 149297.
Is there an easy way to change this in the code, for those who prefer tabs on
top?  Perhaps a line or two?
Whether you like tabbed browsing or not, the fact is that Mozilla 1.0 shipped
with 'Open link in new tab' at the top, so I think it should stay that way for
1.x. If you change this for 1.1, all the people who were annoyed at first, but
then got used to it, will be annoyed again. 
Excuse me, but it seems to me that the majority of the comments here is in
favour of the 1.0 order (first tab, then window).

In view of this, then why was this change made?

Please don't say "menu consistency". Menu consistency would have been preserved
if the Tab item had appeared first in the context menu _and_ in the menus too
(as it should be, IMHO).

Also, please don't say "because 4.x had 'open link in new window' as the first
context menu item". 4.x did not have tabs, and tabs are one perhaps *the* single
most visible advantage that mozilla has compared to over 4.x and most other
browsers.

I think this is a step backwards from 1.0, and it changes what 1.0 users will
have gotten used to. It should be backed out. Does anyone agree with me?
Personally, I'm strongly in favor of restoring the context menu to the classic
"New Window" above "New Tab" arrangement, not only for consistency with the
current version of IE, Netscape, and every Mozilla beta over the past two years,
but because a new window is so much more useful than a new tab (e.g. you can
view pages side-by-side).

Too many designers have developed their interfaces with a priority on showcasing
new features (such as the tabbed interface), instead of usability.  Since some
of you have used this as a reason to place "Open in New Tab" on top, I would
like to  suggest that this is not such a great motivation.

The only time I ever open a new tab is when I *meant* to open a new window. 
Although the new context menu arrangement has been in effect for more than two
months, and I still haven't trained myself to use it properly without thinking
first.  Perhaps ten years of motor memory should take precedence over
"discoverability."

I hate tabs.  Ideally, I'd like a way to disable the tabbed interface entirely
and hide all related menu items.
D.A. Karp, what you're saying is that you hate tabs and don't want to use them,
so the Open in new Tab menu is useless to you. I have two comments about this:

1. Why not use middle-click or ctrl-click to open in a new window? It's faster
than using a context menu, even if you have motor memory.

2. You probably hate tabs because you've never really tried to use them. They
complement windows nicely: you can group related pages as tabs in a window, and
unrelated pages in new windows. Tabs are faster, take up less screeen space, and
don't clutter the taskbar. Plus, "load links in the background" is a real time
saver: when you open a new link, you don't have to go back to your current
window, you can just go on reading. I didn't like tabs either, but now I'm
hooked. You should try using them.
Lorenzo, you start with the wrong assumption that everybody will like tabs once
they get used to them. However, this is not true. Tabs prevent you from easily
switching to the correct browser tab, you need two clicks now instead of one
(one for the window, one for the tab). Also, you loose overview on the windows
you have open. Grouping related sites together isn't important, at least for me.
I can find them by looking at their titles.

>1. Why not use middle-click or ctrl-click to open in a new window? It's faster
>than using a context menu, even if you have motor memory.

Using, e.g., Microsoft's Intellimouse software, this is not possible.

>2. You probably hate tabs because you've never really tried to use them.

Uhhh. This is a _very_ dared statement.

> Tabs are faster,

That is a seperate bug.

> take up less screeen space,

No, they take up more, because they require the tabbar.

> and don't clutter the taskbar.

Which is why I dislike them.

> Plus, "load links in the background" is a real time saver:

That should be implemented for windows too, the concept isn't tab specific.

By the way, D. A., this bug is fixed, so that "open in new window" is now at the
top again.
Please, can we keep the tabs advocacy (either for or against) out of this bug?
Whether tabs are good or not is a tangent.
It seems to me it is necessary to consider the merits of tabs and windows to
reach a conclusion as to which should be favored by the most conveniently
positioned item in the context menu. It is unhelpful to discourage discussion of
the merits, or to refer vaguely to alleged advantages of tabs or windows,
without explaining what advantages and why the point favors one position or the
other on this bug (as in some earlier posts).

"Open in New Window" has at least 3 objective advantages over "Open in New Tab".
(1) The tab bar takes a significant amount of window space; a new window does
not take any additional screen space. (2) Using separate windows allows
navigation among them with the convenient Alt + Tab, while tab-to-tab requires
using the mouse. (3) Most of those who use tabs at all use both tabs and
multiple windows, while others use windows only. Therefore "Open in New Window"
is what is useful in common to both groups, while "Open in New Tab" serves one
group only.

My vote is with those who have requested a way to turn off all tab-related UI
(and if you turned it on, you could have "Open in new tab" on top). Seems to me
that would suit just about everyone. But if we can't have that, "Open in New
Window" is second-best.
Either leave it alone or come to a conclusion quickly.  I don't care which way 
it is, as long as it's consistent.  Every time I use a different build, it seems 
like it's switched around again.  Just pick one and stick with it.  Once you get 
used to it, it doesn't really matter which way it is, as long as it stays that 
way.
Guys, this bug is fixed. Open in new tab is now below open in new window. Please
stop adding comments about how much you feel that this should be fixed or how
you think a conclusion should be made; a conclusion /has/ been made and this bug
/is/ fixed.

If you still wish to debate which item should be first, or if you feel there
should be a pref for it (there shouldn't), or if you have any other suggestions,
please take it to the netscape.public.mozilla.ui newsgroup.
Keywords: adt1.0.1
adding adt1.0.1-.  Too late to change for the branch.
Keywords: adt1.0.1adt1.0.1-
> Guys, this bug is fixed. Open in new tab is now below open in new window. 
> Please stop adding comments about how much you feel that this should be fixed 
> or how you think a conclusion should be made; a conclusion /has/ been made 
> and this bug /is/ fixed.

This may detract from the developers working on something else; so be it. But I
want to make my opinion known (as have many others here) that I feel that the
fix *is* the bug. If I've got tabbed browsing enabled, it's because I don't want
any new windows open, and if the "new windows" option has gotta be on the
context menu, it damn well shouldn't be first.

A similar issue (I'll probably open a different bug report for this one) is that
I want the option in the Edit->Preferences to make a link that defaults to
opening in a new window to instead open in a new tab....because like I said...if
I'm doing tabbed browsing, its because I don't want new windows opening up on me....

Component: User Interface Design → Browser-General
Keywords: mozilla1.0.2
FYI, drivers do not want this "fixed" on the 1.0 branch -- we do not believe
that significant UI changes are appropriate there, and menu item reordering
counts as significant.

BTW, I sympathise with those tab users who do not want open-new-window to be
first. Did anyone file a new bug asking for a better solution than what was done
for this bug?

/be
Product: Browser → Seamonkey
v
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: