Mailinglist Archive: opensuse-features (11 mails)

< Previous Next >
[openFate 301791] "Report a bug" a-la-Safari for Mozilla Firefox
  • From: fate_noreply@xxxxxxx
  • Date: Thu, 13 Nov 2008 23:56:26 +0100 (CET)
  • Message-id: <feature-301791-28@xxxxxxxxxxxxxx>
Feature changed by: Stefan Behlert <behlert@xxxxxxxxxx>
Feature #301791, revision 28
Title: "Report a bug" a-la-Safari for Mozilla Firefox

openSUSE-11.0: Rejected by Stefan Behlert <behlert@xxxxxxxxxx>
reject date: 2008-10-14 10:33:33
reject reason: Clearly not done
Requester: Mandatory
Projectmanager: Desirable
Archs: i386, x86-64

openSUSE-11.1: Evaluation
Requester: Mandatory
Projectmanager: Important

SLED-11: Candidate
Requester: Mandatory
Projectmanager: Important
Archs: i386, x86-64

Requested by: Guy Lunardi <glunardi@xxxxxxxxxx>
Partner organization:

Apple's Safari web browser introduced a really easy for end-users to
report public URLs which didn't render properly in Safari.
It would be very nice if we could offer something similar for our
what you should be able to send:
- Once Address URL
- Description
- Problem: other problem, missing content, imcorrect behavior,
incorrect aspect, empty page, unable to load the page or unable to
- Send screenshot
- Send source code

#1: JP Rosevear <jpr@xxxxxxxxxx> (2008-02-28 23:27:20)
How is this fundamentally different from Help->Report Broken Website in
I guess code is not sent nor is the screenshot, but this is all the
upstream developers are requesting. Or are you intending submission to

#2: Guy Lunardi <glunardi@xxxxxxxxxx> (2008-03-05 18:26:47) (reply to
JP, thanks for pointing this out. The solution is very close right now.
What it doesn't support is the sharing information for pages that are
'Intranet-based' and not 'Internet-based'.
One of our customer may want to report a problem with Firefox with an
homegrown application which the developers looking at the results of
this submission can't access. Embedding the results (as MTHML or html
source) would be the one missing feature.
The other thing is that this content probably goes upstream. Should it
come to Novell?

#3: Gary Ekker <gekker@xxxxxxxxxx> (2008-05-09 10:23:42)
Michael, does this like something you could do? Or do we need to find
another developer?

#4: Michael Wolf <maw@xxxxxxxxxx> (2008-05-30 18:27:09) (reply to #3)
Not sure yet, but I'll look into it.

#6: Gary Ekker <gekker@xxxxxxxxxx> (2008-09-11 19:00:59)
Proxying this for Michael:
It seems like the best thing to do would be to use what's already in
place. The reporting functionality can be configured.
The source to the reporter contains the following:
| pref("extensions.reporter.privacyURL",
"";); | pref("extensions.reporter.
serviceURL", "";);
They can be changed in about:config, presumably sitewide. (This might
need to be hooked into the gconf stuff.)
So I think it would be a matter of setting up a hypothetical and/or The
source for the server-side part of the reporter is at hosted on mozilla
cvs and can be checked out with "cvs -d :pserver:
anonymous@xxxxxxxxxxxxxxxxxxxxxx:/cvsroot co mozilla/tools/reporter"
The maintainers of said server(s) could then deal with problem reports
as seems fit.
If we choose in SLED to change the default to the hypothetical, it would be trivial to do so via the
MozillaFirefox-branding-SLED package. (I don't think this package
actually exists yet.)

#7: Gary Ekker <gekker@xxxxxxxxxx> (2008-09-11 19:01:59)
Adding Federico and Stano as we might want to look at this in the
context of onstar.

#8: Stefan Behlert <behlert@xxxxxxxxxx> (2008-10-14 10:34:08)
What's the status here?

#9: Stefan Behlert <behlert@xxxxxxxxxx> (2008-10-24 17:23:17) (reply to
Gary, Michael?

+ #10: Stefan Behlert <behlert@xxxxxxxxxx> (2008-11-13 23:46:50)
+ Guy, we need to reject this as there was no progress.
+ Gary, could you provide an ECO for that?

openSUSE Feature:

< Previous Next >
This Thread
  • No further messages