256368 - Add link(s) to reporting tool in Firefox

Status: RESOLVED DUPLICATE of bug 280597

(Firefox :: Menus, enhancement, P1)

Description

[Robert Accettura [:raccettura]]

As we get ready to implement (at least part of) the reporting tool, we need to
get some links, so users can easily access the tool.

Ideally, it would be situated in the Help Menu with 'Tell A Friend' and 'Promote
Firefox'.  

At a minimum, we need a bookmark.

Optimally in addition to the Help menu, we need a link in the bookmark toolbar
on a default profile setup.

ideal link format would be:
http://reporting.mozilla.org/?url=http://host.tld/dir/page.html

With the last part obviously being the current URL of the visible tab so that
user does not need to copy/paste the URL.

I'll file a separate bug for seamonkey.

Per discussion with Asa, we need to do this *quick* for localization freeze reasons.

Comment 1

[Robert Accettura [:raccettura]]

Bug 256369 is for seamonkey

Comment 2

[Robert Accettura [:raccettura]]

Asa,

Please confirm:
reporting.mozilla.org

or:
reporter.mozilla.org

Comment 3

[Asa Dotzler [:asa]]

I like "reporter".  It's got the feel of a tool name where "reporting" doesn't.

Comment 4

[Robert Accettura [:raccettura]]

Can I assume that to be a decision with driver approval?  Or do you still need
to confer with others?

Comment 5

[Robert Accettura [:raccettura]]

Attachment: Menu Patch (v1)

This adds the option to the help menu.

Upon selecting the option, it would automatically pre-populate the URL field,
so that we can get the exact URL of the website being reported without typo's.

Comment 6

[Robert Accettura [:raccettura]]

Attachment: Bookmarks Patch (v1)

This patch, is a supliment/replacement.  Ideally a suplement.

This adds a link to reporter in the bookmarks, as well as the bookmark toolbar.
 In the bookmark toolbar, it would is a Jesse Ruderman inspired bookmarklet to
also capture the URL, and prepopulate it into the form.

This has the advantage of being in a new users field of vision the first time
they cross a problem.  So there is an advantage.

But of course, it's another default bookmark... and who really wants mozilla
making decisions for you?  

I realize that, but there are advantage, so I throw the idea out there, so they
can be weighed.

Comment 7

[Robert Accettura [:raccettura]]

I'm not configured to build here, so these are untested patches.  Will need
someone to take a close look at them.

Though they are pretty strait forward (menu is pretty much a copycat of blake's
checkin a week or two ago), bookmarks is trivial.

Asa,

Can you oversee this as you so brilliantly do?

Comment 8

[Robert Accettura [:raccettura]]

Attachment: Menu Patch (v2)

Proofreading is a virtue

Comment 9

[Robert Accettura [:raccettura]]

Asa,

I think all systems go for implementing phase I in time for Firefox 1.0PR.  

I'm on standby pending infrastructure, and reviews on patches.

I leave that to you.

Comment 10

[Robert Accettura [:raccettura]]

A potential problem here (though not to big) is intranet sites being reported.

AFAIK Mozilla isn't aware of intranet/extranet since we don't have 'zones'.  So
the only possible solution would be a pref where an admin can enter domains to
not report for.

I think that's another bug, since it's not critical.  But something perhaps for
the future.

Right now I'm just hoping to get this in place in time for localization (which
is another discussion we should have... localizing the entire r.m.o isn't
something I'd be for, but perhaps the submission form?  The only downside there
is getting submissions in various languages (and whose going to read them).

Comment 11

[Asa Dotzler [:asa]]

Robert, I've talked with the project folks and it sounds like it's too late for
Firefox 1.0 to get this into the actual product. We should work with Jay (our
Talkback guy) to get the tool set up on one of our servers and to get the UI
into the Firefox and SeaMonkey trunk builds and for the Firefox 1.0 users,
provide web interface links from Bugzilla and elsewhere so that people can get
access to the tool, even if it's a bit clumsy. 

Comment 12

[Robert Accettura [:raccettura]]

Changing target

It would be nice to have a post 1.0 milestone timeline (even if it is rough), so
the community has an idea of what's to come.  So far there's a wall at 1.0, and
a mystery on the other side.  Looking forward a milestone or two ahead would
help for bugs like this.

Comment 13

[Asa Dotzler [:asa]]

the trunk is where the post 1.0 changes are happening and we haven't figured out
how we're going to name Firefox releases from the trunk yet. This could land on
the trunk pretty much as soon as it's ready to. 

Comment 14

[Robert Accettura [:raccettura]]

Were better off not landing until we have the r.m.o form setup... or at a
minimum some sort of temporary page.

Otherwise, were going to be seeing unnecessary bugs as daily testers are quite
diligent ;-).

Comment 15

[Robert Accettura [:raccettura]]

Comment on attachment 156690 [details] [diff] [review]
Menu Patch (v2)

Plan now is a bit more elaborate...

I have an XUL frontend for this in my personal dev environment.  

When we get a test server setup... we'll get cracking.

Comment 16

[Robert Accettura [:raccettura]]

Marking as a dup, this bug is antequated and somewhat irrelevent.

*** This bug has been marked as a duplicate of 280597 ***