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.
Bug 256369 is for seamonkey
Priority: -- → P1
Target Milestone: --- → Firefox1.0beta
Asa, Please confirm: reporting.mozilla.org or: reporter.mozilla.org
I like "reporter". It's got the feel of a tool name where "reporting" doesn't.
Can I assume that to be a decision with driver approval? Or do you still need to confer with others?
Created attachment 156688 [details] [diff] [review] 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.
Assignee: firefox → robert
Status: NEW → ASSIGNED
Created attachment 156689 [details] [diff] [review] 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.
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?
Attachment #156688 - Attachment is obsolete: true
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.
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).
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.
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.
Target Milestone: Firefox1.0beta → After Firefox 1.0
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.
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 ;-).
Version: unspecified → Trunk
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.
Attachment #156690 - Attachment is obsolete: true
Marking as a dup, this bug is antequated and somewhat irrelevent. *** This bug has been marked as a duplicate of 280597 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.