Replacement of "Report a Broken Website" with new Feedback System
Aakash Desai
I started 6 months ago on an endeavor to reboot Firefox's "Report a Broken Website" feature by trying to do two simple things: extend its support over to Mobile Firefox and revamp reporter.mozilla.org's user experience. Thanks to Mario Alvarado, we were able to accomplish one of those feats in introducing Reporter for Fennec [1].
Unfortunately, while beginning to work on the second feat, I realized that there was **no one** actively maintaining or using the system on Firefox. On top of that, there were a variety of unmet feedback needs [2] not properly solved by that or any of our current feedback systems. So, a new, more flexible feedback system has been formulated and is being implemented right now [3] for both Firefox and Mobile Firefox. With this new system, though, we'll need to archive reporter.mozilla.org and remove the "Report a Broken Website" feature from Firefox Proper. For those who are fine with this, there's no reason to read further and you can go on with your day.
For those that are worried about this, the following links will help offer a better idea of what the system does, how it works and when we plan to ship it:
- Project Wiki [3]
- **Rough** Workflow Mock-ups [4]
So, if there any objections to this plan or if anyone has a grounded reason as to why this new system may not work for them in place of the "Report a Broken Website" feature, please bring up your concerns on the action item bug [5] and we'll try to alleviate them as much as possible.
Thank You for Your Time,
Aakash Desai
[1] https://addons.mozilla.org/en-US/mobile/addon/87500
[2] https://wiki.mozilla.org/Firefox/Input/Needs
[3] https://wiki.mozilla.org/Firefox/Input
[4] http://www.flickr.com/photos/aakashhdesai/sets/72157624035832688/
[5] https://bugzilla.mozilla.org/show_bug.cgi?id=572026
David E. Ross
I'm confused. Is "Report a Broken Website" being removed as a
capability? Or is it being made to work better?
Also, why do none of your paragraphs wrap when I quote them in this reply?
--
David E. Ross
<http://www.rossde.com/>.
Anyone who thinks government owns a monopoly on inefficient, obstructive
bureaucracy has obviously never worked for a large corporation. © 1997
Daniel
Just as a by-the-by, David, when I hit "Reply" to your message, Aakash
Desai's lines were still strung out.
Didn't you "Edit->Rewrap" Aakash's message, David?
(I have....I wonder if it will stick!!)
Daniel
Axel Hecht
<...>
>
> Also, why do none of your paragraphs wrap when I quote them in this reply?
>
https://bugzilla.zimbra.com/show_bug.cgi?id=22951
Yeah, annoying. My local trick is to reply with html mails ;-)
Axel
Aakash Desai
Yes, we're removing the "Report a Broken Website" as a capability and a new system is being implemented that makes submission for those issues easier and less cost.
Also, I did copy-and-pasted this e-mail from a text editor, so that may be why my paragraphs are not wrapping for you.
Hope that Helps,
Aakash
----- Original Message -----
From: "David E. Ross" <nob...@nowhere.invalid>
To: dev-pl...@lists.mozilla.org
Sent: Monday, June 14, 2010 10:52:55 PM
Subject: Re: Replacement of "Report a Broken Website" with new Feedback System
On 6/14/10 5:33 PM, Aakash Desai wrote:
> Hi,
>
> I started 6 months ago on an endeavor to reboot Firefox's "Report a Broken Website" feature by trying to do two simple things: extend its support over to Mobile Firefox and revamp reporter.mozilla.org's user experience. Thanks to Mario Alvarado, we were able to accomplish one of those feats in introducing Reporter for Fennec [1].
>
> Unfortunately, while beginning to work on the second feat, I realized that there was **no one** actively maintaining or using the system on Firefox. On top of that, there were a variety of unmet feedback needs [2] not properly solved by that or any of our current feedback systems. So, a new, more flexible feedback system has been formulated and is being implemented right now [3] for both Firefox and Mobile Firefox. With this new system, though, we'll need to archive reporter.mozilla.org and remove the "Report a Broken Website" feature from Firefox Proper. For those who are fine with this, there's no reason to read further and you can go on with your day.
>
> For those that are worried about this, the following links will help offer a better idea of what the system does, how it works and when we plan to ship it:
>
> - Project Wiki [3]
> - **Rough** Workflow Mock-ups [4]
>
> So, if there any objections to this plan or if anyone has a grounded reason as to why this new system may not work for them in place of the "Report a Broken Website" feature, please bring up your concerns on the action item bug [5] and we'll try to alleviate them as much as possible.
>
> Thank You for Your Time,
> Aakash Desai
>
> [1] https://addons.mozilla.org/en-US/mobile/addon/87500
> [2] https://wiki.mozilla.org/Firefox/Input/Needs
> [3] https://wiki.mozilla.org/Firefox/Input
> [4] http://www.flickr.com/photos/aakashhdesai/sets/72157624035832688/
> [5] https://bugzilla.mozilla.org/show_bug.cgi?id=572026
I'm confused. Is "Report a Broken Website" being removed as a
capability? Or is it being made to work better?
Also, why do none of your paragraphs wrap when I quote them in this reply?
--
David E. Ross
<http://www.rossde.com/>.
Anyone who thinks government owns a monopoly on inefficient, obstructive
bureaucracy has obviously never worked for a large corporation. © 1997
_______________________________________________
dev-planning mailing list
dev-pl...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-planning
Robert Kaiser
> With this new system, though, we'll need to archive reporter.mozilla.org and remove the "Report a Broken Website" feature from Firefox Proper.
This will also need removing it from SeaMonkey. Would have been nice if
we have been informed earlier, but who cares anyhow.
Robert Kaiser
David McRitchie
> I realized that there was **no one** actively maintaining or using the system on Firefox.
Is that part telling us that all of the people we suggested using "report a broken link"
to get help, that their requests end up in a dead-letter box -- that would be so
like Hendrix.
Asa Dotzler
It's always nice to know everything earlier, but this work has been
ongoing for months, with docs in the wiki and noted in the weekly
project-wide meeting so it shouldn't be a total surprise.
That being said, I'll bet it's not terribly difficult to remove. Also, I
wonder if the SeaMonkey team was actually using Reporter data to triage
website compatibility issues. I haven't seen any bugs filed by you (or
really anyone else, for that matter) with Reporter links.
- A
Asa Dotzler
You were telling folks that Reporter would give them help? Then you
don't understand what it was built for.
I designed reporter to be sort of like talkback/breakpad, where we could
collect and analyze *aggregate data* on websites that weren't working so
we could either file bugs on Gecko if it was at fault, or maybe reach
out to websites to try to get them to update their code if it was their
fault.
It was never intended as a means for delivering help to end users and
anyone telling end users they'd be helped directly through that channel
was doing those users a disservice.
- A
Aakash Desai
> Is that part telling us that all of the people we suggested using "report a broken link"
> to get help, that their requests end up in a dead-letter box -- that would be so
> like Hendrix.
Aye, that's the unfortunate part of the matter. We want to fix that problem with providing this new solution. Would you be interested in being one of our triagers for the new system? The help we can get, the more likely this new system won't die like our previous mechanisms.
Thanks,
Aakash
----- Original Message -----
From: "David McRitchie" <fire...@verizon.net>
To: dev-pl...@lists.mozilla.org
Sent: Tuesday, June 15, 2010 8:51:32 AM
Subject: Re: Replacement of "Report a Broken Website" with new Feedback System
Robert Kaiser
> That being said, I'll bet it's not terribly difficult to remove.
Sure, as I said, who cares anyhow, I just would have liked to know.
Robert Kaiser
David McRitchie
Some users actually mentioned that "Report a Broken website" would get
someone from evangelism to look at it, and where did that loose
connection come from, guess if they read your blog they would realize
that both "Report a Broken Website" (in Firefox help) and "Hendrix" (talk back?)
do not get help, in fact neither serve the
purpose they were intended to because developers don't look at it and
want someone to summarize Hendrix for them. But from a user's point
of view (only Hendrix tells tells them not to expect an answer) but they still
feel that is their only method of contacting Mozilla or Firefox (often as if they
are a person) and get no help. I think some of them expected to get help
from the support.mozilla.com/kb help articles when the article failed to
answer their question.
Hendrix probably causes more people to say they are leaving Firefox
forever than anywhere else because there is no feedback.
It certainly gets attention of people who want help, needs to
be turned around to provide help. It is in fact getting more questions
asked there than in mozilla.support.firefox
"Report a Broken Website" is in Help, is not going to provide
user help, if Aakash can turn it around to help developers and
not confuse users that would be helpful.
"Report a web forgery" goes directly to Google and
I can tell you that does not work, if the forger is a Google partner,
maybe if they were phishing a bank it might get results.
In any case they are "feedback to developers" supposedly for
bug reports, and developers don't pay attention to it.
Here is what I found on searching, so everything is for bean
counting for developers, and regardless of being part of help
is not intended to provide help to users at all.
Asa Dotzler - Firefox and more: report a broken website
http://weblogs.mozillazine.org/asa/archives/008161.html
Asa Dotzler - Firefox and more: answers to ask asa
http://weblogs.mozillazine.org/asa/archives/007637.html
Hacking for Christ: Introducing 'Hendrix'
http://weblogs.mozillazine.org/gerv/archives/007271.html
Mike Beltzner
Hey Robert,
I'm not sure what Aakash (or anyone) is supposed to do with this feedback. He's writing to this group to tell you that the current proposal is to remove the old feature and replace it with this new functionality, and providing background (annotated with links!) to the meetings and discussions (all done in public) which led to this proposal.
What's happening now is pretty standard: those with a proposal are widening the net, asking others for feedback and specific concerns and objections.
If you need us to keep the feature alive for a period of time, please let us know. It's hard to understand why that would be something you'd want, since from our analysis, nobody was looking at the data that was being collected, so it's not like it was doing your users any good.
If you'd like to know how to migrate SeaMonkey to use this new feature, that's a pretty reasonable thing to ask!
cheers,
mike
Robert Kaiser
> On 2010-06-15, at 12:18 PM, Robert Kaiser wrote:
>
>> Asa Dotzler schrieb:
>>> That being said, I'll bet it's not terribly difficult to remove.
>>
>> Sure, as I said, who cares anyhow, I just would have liked to know.
>
> Hey Robert,
>
> I'm not sure what Aakash (or anyone) is supposed to do with this feedback. He's writing to this group to tell you that the current proposal is to remove the old feature and replace it with this new functionality, and providing background (annotated with links!) to the meetings and discussions (all done in public) which led to this proposal.
I guess I was in a somewhat bad mood when I read this, and I usually am
happier to not read this in a manner that tells "I am working on this
for 6 months for Firefox and now it's almost here" when I don't know yet
that it affects SeaMonkey as well - even though I probably should
already be used to that. ;-)
> If you need us to keep the feature alive for a period of time, please let us know. It's hard to understand why that would be something you'd want, since from our analysis, nobody was looking at the data that was being collected, so it's not like it was doing your users any good.
No, that's why I said "who cares" as I know that as much as it was
thought to become potentially a good feature for evang efforts towards
website, that never manifested (like so much in that area), and on our
(Mozilla) side, nobody really cared too much about those reports, so
nothing's really lost.
> If you'd like to know how to migrate SeaMonkey to use this new feature, that's a pretty reasonable thing to ask!
I won't believe that to be necessary unless I see this new effort to
really work better then the last one.
What I worry more about is us needing to do patches on our side when
reporter gets removed. That should be nothing that is hard to do, just
something we should know about.
Robert Kaiser
Phillip Jones
just within the last couple of weeks. Even though I did so hoping
someone would twist the arm of the website owner. I figured it was just
really so unsuspecting user of it would feel good that they were trying
to help. Just like some of use post bugs and the <quote>
Experts</quote> just roll their eyes and say him again/ her again let
just ignore it they don't know what they are talking about anyway.
--
Phillip M. Jones, C.E.T. "If it's Fixed, Don't Break it"
http://www.phillipmjones.net mailto:pjo...@kimbanet.com
Phillip Jones
the Mozilla collective could contact the website owner and say hey we
have these report about your website. I never thought it was so I would
get feedback/help from Mozilla about the site. If the site is coded bad,
its coded bad and the web designer need to fix it, not Mozilla.
Phillip Jones
How do we report bum websites In the General Users Group wher non of
the head Honchos even look at?
David E. Ross
I submit Tech Evangelism bug reports. However, I have advised other
users who do not have Bugzilla accounts and would find submitting a bug
report to be excessively daunting that they should use the "Report a
Broken Website" feature. Only now do I discover that the feature is a
black hole, that no report made through it will be acted upon.
When the decision is made to remove a capability -- even a dead-end
capability -- or to make a major change in a capability, it should be
announced here, not when implementation is almost done but when the
decision is initially made.
No one -- NO ONE -- can review and track all bug reports. No one can be
cognizant of all pending changes merely by following bug reports.
Asa Dotzler
>
> How do we report bum websites In the General Users Group wher non of the
> head Honchos even look at?
>
Starting to head off-topic for this group, but I'd say that unless
you're willing to testcase it, then I wouldn't bother. Better to spend
your time writing webm...@bum-website.com and telling them that you're
an unhappy customer and you'll be taking your business elsewhere.
If it's a major site and it's broken because of a change in Firefox and
you can determine which day's build broke it, then a bug would probably
be appreciated even without a reduced testcase.
The days when we had to do labor-intensive outreach (at least in the
West) to top 1000 sites are gone. We needed it to bootstrap growth, but
today if a site isn't supporting Firefox, they're out a very large chunk
of their users so if it's their fault, they're likely to want to fix it
and an email from an upset customer will probably help. If the problem
is our fault, they're probably still try to work around it but if we're
going to do something about it then we'll need a testcase or a
regression window to make any progress and if you can help with that, a
Bugzilla report is much better than hendrix or reporter.
- A
Asa Dotzler
I chased the Reporter reports for a quite a while. It hasn't always been
a black hole but without sufficient volunteer help in triaging those
lists, the database eventually became mostly useless. If no one's going
to act on the feedback, there's no point in continuing to gather it
(except that it can divert people from making useless reports in more
focused environments like Bugzilla).
Perhaps when Aakash gets his new tool running, you and others will step
up to help maintain the database, surfacing common issues and
translating them into bug reports where appropriate. With sufficient
help, it could be a valuable tool.
That being said, it wasn't completely ignored. I monitor Reporter and
Hendrix reports right after releases to see if there are any spikes in
specific problems or sites. I've been doing this for quite a while right
after our releases (along with the Firefox Release Rapid Response Team)
and so far I haven't found any regressions from the Reporter data in
those few days after a release. Hendrix, yes, Reporter, nope. Probably
just not enough volume to be useful for that purpose.
- A
David E. Ross
As I mentioned earlier in this thread, I had the same understanding of
"Report a Broken Website" as Phillip Jones. That is, it would be a tool
for users who do not understand Bugzilla, a tool in lieu of submitting a
Tech Evangelism bug report.
Many, many responses in mozilla.support.seamonkey to queries about
problems viewing Web sites -- especially invalid sniffing -- told users
that they should go the [Help > Report a Broken Website]. Why, after so
many years of such advice, are we only now learning that it was the
wrong advice?
David E. Ross
What you are saying is that Tech Evangelism bugs are worthless. Is that
really true?
Boris Zbarsky
> The days when we had to do labor-intensive outreach (at least in the
> West) to top 1000 sites are gone. We needed it to bootstrap growth, but
> today if a site isn't supporting Firefox, they're out a very large chunk
> of their users so if it's their fault, they're likely to want to fix it
> and an email from an upset customer will probably help.
Sort of. Trying that with a beta build gets a pretty negative response
all around when I've tried, and a pretty large number of sites are
broken in our nightlies and betas, comparatively speaking (two of the
three bank sites I use on a regular basis are both broken, for example).
Major sites like live.com don't work on trunk because of broken UA
sniffing. That sort of thing interferes with us getting the nightly and
beta feedback we need...
Unfortunately, I don't have a good solution to the problem (use random
UA strings? Send Firefox in the UA no matter what? something else?).
-Boris
Boris Zbarsky
One other note. While true, this is not something we should overrely on.
The end of the road there is the way web developers feel about IE6.
> but if we're going to do something about it then we'll need a testcase or a
> regression window to make any progress
Not necessarily. We do have people who can produce both of those. If
it's a regression, all we really need is being told that plus clear
steps to reproduce (including a clear description, using screenshots if
need be, of what the problem is and how to tell whether you hit it).
Once we have that, finding the regression range is a 10-15-minute job
(10 builds, one minute per build, covers more than 2 years of nightlies).
-Boris
Aakash Desai
So, this discussion has gone a bit off-topic as a lot of the feedback has been geared around two things from what I can see:
1. Not enough communication when this plan was first finalized
2. No one was looking through the report sent in to reporter.mozilla.org
For the first point, I'd like to cut out the discussion and say that this plan wasn't finalized until about 2-3 weeks ago. It should have been mentioned from the onset rather than right before it's about to be completed, so I'll make sure to post to dev-planning in the future before starting the endeavor (to only garner **constructive** feedback).
As for the second point, unfortunately we as a community caused that to happen. The only way to fix that is to keep it live and going. I've added a section to the project wiki to ask for volunteers I can call upon to help triage, trend and/or report the data submitted by Input (**especially** the system once it's on a staging server). It's located here: https://wiki.mozilla.org/Firefox/Input#Volunteers
I'm hoping that those who have spoken out about this in this thread are the first to sign up. Once a more set proposal of actions is set, expect an e-mail from me.
Thanks,
Aakash
----- Original Message -----
From: "David E. Ross" <nob...@nowhere.invalid>
To: dev-pl...@lists.mozilla.org
Sent: Tuesday, June 15, 2010 2:19:09 PM
Subject: Re: Replacement of "Report a Broken Website" with new Feedback System
> How do we report bum websites In the General Users Group wher non of
> the head Honchos even look at?
>
I submit Tech Evangelism bug reports. However, I have advised other
users who do not have Bugzilla accounts and would find submitting a bug
report to be excessively daunting that they should use the "Report a
Broken Website" feature. Only now do I discover that the feature is a
black hole, that no report made through it will be acted upon.
When the decision is made to remove a capability -- even a dead-end
capability -- or to make a major change in a capability, it should be
announced here, not when implementation is almost done but when the
decision is initially made.
No one -- NO ONE -- can review and track all bug reports. No one can be
cognizant of all pending changes merely by following bug reports.
--
David E. Ross
<http://www.rossde.com/>.
Anyone who thinks government owns a monopoly on inefficient, obstructive
bureaucracy has obviously never worked for a large corporation. © 1997
Asa Dotzler
> Many, many responses in mozilla.support.seamonkey to queries about
> problems viewing Web sites -- especially invalid sniffing -- told users
> that they should go the [Help> Report a Broken Website]. Why, after so
> many years of such advice, are we only now learning that it was the
> wrong advice?
>
Who in SeaMonkey land was telling you to tell users that. Perhaps that
person was doing something with those reports.
- A
Phillip Jones
Several Years ago I had a problem with my bank website Suntrust.
SeaMonkey the browser of choice for me couldn't show Correctly and
neither could FireFox. I had to use opera or iCab which has the
capability built in to spoof the UA it ended up that only IE was
allowed. I hounded Suntrust until they made a Change. Turns out they set
UA sniffing to FireFox not Gecko. I threw up my hands so for years until
SM 2 came out I used UASwitcher. or add "/not FireFox/3.0" to end of UA
String.
One person person alone reporting wrong Browser sniffing is not going to
do anything. and Many sites don't even have a place to report website
problems. They contract out to a web design place who doesn't want
niggling details. individual customers so far as site design is
concerned get no more consideration than a gnat. They only way change
can be affected is if you have a big organization such as Mozilla,
Microsoft, Opera, iCab Omni or so on to say web designer you have a
problem here are the reports
The days of the customer is king is long gone it died in the 80's
Companies now as long as you use their product that's great when it
comes to support for the product your just out of luck.
Aakash Desai
http://www.flickr.com/photos/aakashhdesai/4596445261/in/set-72157624035832688/
The negative submission page will still give users the option to add in the URL they are having an issue with as well as add comments. In fact, I believe this will be an easier workflow than the current method to do it!
Hope that Helps,
Aakash
----- Original Message -----
From: "Phillip Jones" <pjo...@kimbanet.com>
To: dev-pl...@lists.mozilla.org
Sent: Tuesday, June 15, 2010 4:37:42 PM
Subject: Re: Replacement of "Report a Broken Website" with new Feedback System
Phillip Jones
I heard it as well from many of the experts the SeaMonkey.support Group.
I think at one time even Chris I suggested it. May of the co-moderators
at least once . For Myself I went several times to Report because it
said in help menu :
http://screencast.com/t/YTEzNzA5N.
One assumes if *Report Broken Websites* is in help menu that is what
you are supposed to do. had I known otherwise I would just reported in
the SeaMonkey support to warn other of the problems.
Robert Kaiser
> The days when we had to do labor-intensive outreach (at least in the
> West) to top 1000 sites are gone.
That's true for having them work in Firefox, but not for Minefield or
SeaMonkey, as browser sniffing for the word "Firefox" in unfortunately
all too common nowadays. OTOH, I'm not sure if there's any good chance
to get hose fixed, esp. as even the .NET framework seems to do it,
which many people are using for constructing websites without knowing
that browser sniffing is even happening.
Robert Kaiser
--
Note that any statements of mine - no matter how passionate - are never
meant to be offensive but very often as food for thought or possible
arguments that we as a community needs answers to. And most of the time,
I even appreciate irony and fun! :)
Robert Kaiser
> Unfortunately, I don't have a good solution to the problem (use random
> UA strings? Send Firefox in the UA no matter what? something else?).
I've had an idea running around for a few years now, which combines an
add-on for targeted sniffing with a warning system for the user and an
access point to doing evang work, e.g. sending messages to the website
maintainers - but due to multiple issues, including technical problems
with even creating the add-on in the first place, this has never
manifested itself.
Robert Kaiser
> 1. Not enough communication when this plan was first finalized
>
Yes, let's leave it at that, the warning still came in before it
actually happened, so I guess we'll should fine in the end anyhow. Could
you please CC me (same email as in here) to the relevant bug report so I
can react on our side? Thanks.
Robert Kaiser
Asa Dotzler
> Asa Dotzler schrieb:
>> The days when we had to do labor-intensive outreach (at least in the
>> West) to top 1000 sites are gone.
>
> That's true for having them work in Firefox, but not for Minefield or
> SeaMonkey, as browser sniffing for the word "Firefox" in unfortunately
> all too common nowadays. OTOH, I'm not sure if there's any good chance
> to get hose fixed, esp. as even the .NET framework seems to do it, which
> many people are using for constructing websites without knowing that
> browser sniffing is even happening.
>
> Robert Kaiser
>
If it's bad browser sniffing, I'd wager that user complaints to the
website will go a lot further than user complaints to Mozilla.
- A
Asa Dotzler
> One person person alone reporting wrong Browser sniffing is not going to
> do anything. and Many sites don't even have a place to report website
> problems. They contract out to a web design place who doesn't want
> niggling details. individual customers so far as site design is
> concerned get no more consideration than a gnat. They only way change
> can be affected is if you have a big organization such as Mozilla,
> Microsoft, Opera, iCab Omni or so on to say web designer you have a
> problem here are the reports
Yeah. That was my theory 6 years ago. Turns out we never did that with
the Reporter data like I had planned when I first conceived of the tool.
Mozilla really hasn't been doing this kind of outreach since 2001 or
2002 when the Netscape Tech Evangelism team were literally re-writing
code for broken websites. That was years before Firefox had any market
share and the problem was IE vs. Netscape sniffing. That was years
before Reporter.
If you were under the impression that some "official" Mozilla person or
team was chasing down Reporter identified websites that didn't work in
SeaMonkey or other alternative browsers because of bad browser sniffing,
I'm sorry to burst your bubble, that's just not happening and never has.
I also think you're wrong about what it takes to make change here.
Mozilla never got Firefox sniffing fixed by having executives at Mozilla
contact big websites that showed up in Reporter data. We grew our user
base by having a kick-ass product and those users generated enough log
traffic and complaints directly to sites that sites fixed themselves.
When sites were contacted, it wasn't by some Mozilla executive with
extensive Reporter data. It was individual Mozilla contributors who were
actual customers of those sites telling them they had a problem.
Now, if you all want to rally behind Aakash's new tool (or make the case
to keep Reporter alive for SeaMonkey) then by all means, go for it.
But someone has to watch the data and do the outreach. I don't think
there's a big need for that for Firefox desktop, but SeaMonkey and other
browsers, possibly Firefox Mobile, do still have lots more problems with
site compatibility. There's no free lunch here. If you want to see this
situation improve for SeaMonkey, give your time or find others to do it.
To date, I don't think that's happened at all. Maybe a better tool will
inspire more help in this area.
- A
Boris Zbarsky
> base by having a kick-ass product and those users generated enough log
> traffic and complaints directly to sites that sites fixed themselves.
For some values of "fixed".
> But someone has to watch the data and do the outreach. I don't think
> there's a big need for that for Firefox desktop
Hard to say.
* I can't use Firefox nightly builds of any stripe (trunk or branch)
to manage my FIOS phone settings.
* I can't use Firefox nightlies to usefully schedule my Capital One
credit card payment (this in spite of me having a long mail exchange
with them, including me telling them exactly how to fix the site).
No one with an Irish localization of Firefox of any sort (release,
nightly, whatever) can schedule such payments either.
* Using bill pay in ING's site with a Firefox nightly is a pain
due to it being off the right edge of the viewport all the time.
That's the things I have had not working in Firefox nightlies in the
last 3 days or so. There are a bunch more sites I commonly (at least
once a month) use that force me to use release builds, but I don't have
details off the top of my head.
The common thread in all of these is completely broken UA sniffing,
combined with a "we don't care whether it works in anything that's not a
shipping Firefox build" attitude on the part of the site developers.
The outcome is that we get less testing for our trunk builds (I'm having
a hard time using them for pretty much anything financial nowadays),
which is bad for us, obviously (we ship regressions; I've seen a number
of bugs reported over the years where the regressions were not caught
due to UA sniffing issues).
Could we do something about this via education and outreach about how to
"properly" sniff? I don't know, but it might be nice to try....
-Boris
Asa Dotzler
> Could we do something about this via education and outreach about how to
> "properly" sniff? I don't know, but it might be nice to try....
>
> -Boris
Possible. I doubt it though. Websites might be convinced to sniff
properly to include lesser known released browsers but I suspect the
financial, ecommerce, and medical and whatnot sites out there don't want
users with pre-release versions of software interacting with their
services.
I see two situations. The first is ignorance about sniffing so they're
always breaking when we rev our version numbers or they're sniffing
Firefox and we're called Minefield. In those cases, I suspect an email
from an individual customer is as powerful or more powerful than some
kind of Mozilla education campaign.
The second case is that they're sniffing just right for "browsers we've
tested our site in" and in that case, no amount of education about the
proper way to sniff is going to change their path. They're intentionally
supporting only tested browsers.
The only easy solution for testers of for Firefox pre-release builds is
to spoof the UA. (Also, we should stop calling it Minefield and start
calling it Firefox-devchannel or something that doesn't break the common
"firefox" regexps, IMO. That's not going to solve this problem but might
help a bit and it's also the right thing to do to stop scaring people
away from builds we want tested.)
- A
Boris Zbarsky
>> Could we do something about this via education and outreach about how to
>> "properly" sniff? I don't know, but it might be nice to try....
>>
>> -Boris
>
> Possible. I doubt it though. Websites might be convinced to sniff
> properly to include lesser known released browsers but I suspect the
> financial, ecommerce, and medical and whatnot sites out there don't want
> users with pre-release versions of software interacting with their
> services.
And we, on the other hand, want our pre-release software interacting
with their services. So we have a slight conflict of interest.
> I see two situations. The first is ignorance about sniffing so they're
> always breaking when we rev our version numbers or they're sniffing
> Firefox and we're called Minefield. In those cases, I suspect an email
> from an individual customer is as powerful or more powerful than some
> kind of Mozilla education campaign.
Individual customers can almost never mail the people writing the
website code. The people they _can_ mail have no clue about any of
these issues, and just follow their script and send the mail to
/dev/null (rudely most of the time, politely in some cases).
> The second case is that they're sniffing just right for "browsers we've
> tested our site in" and in that case, no amount of education about the
> proper way to sniff is going to change their path. They're intentionally
> supporting only tested browsers.
One option, of course, is to simply not given them the ability to do
such sniffing. Remove everything from the UA string that would
differentiate two different Firefox builds (see it as a privacy measure
if you want).
This might not be viable, but it would also get people to fix their
sniffing in a hurry if they actually cared....
> The only easy solution for testers of for Firefox pre-release builds is
> to spoof the UA.
The testers aren't the ones with a problem, per se; we are (in that we
don't get useful testing).
> (Also, we should stop calling it Minefield and start
> calling it Firefox-devchannel or something that doesn't break the common
> "firefox" regexps, IMO.
Or just "Firefox"?
> That's not going to solve this problem but might
> help a bit and it's also the right thing to do to stop scaring people
> away from builds we want tested.)
Note that all our messaging and branding around trunk builds is
_designed_ to scare people away. I do think we should revisit that
decision....
-Boris
David E. Ross
[snip]
> I also think you're wrong about what it takes to make change here.
> Mozilla never got Firefox sniffing fixed by having executives at Mozilla
> contact big websites that showed up in Reporter data. We grew our user
> base by having a kick-ass product and those users generated enough log
> traffic and complaints directly to sites that sites fixed themselves.
[snip again]
Log traffic is exactly the reason why permanently spoofing Firefox from
SeaMoneky or any other non-Firefox Gecko-based browser is wrong. If you
permanently spoof Firefox, the Web server logs will indicate that
SeaMonkey and other browsers are not being used. Even permanent
spoofing with something like
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9)
Gecko/20100317 SeaMonkey/2.0.4, NOT Firefox/3.6.3
is wrong because the software that analyzes server logs will see
"Firefox" and report that as the browser.
According to Web developers, there is no need to sniff for Gecko.
Instead, it is sufficient to sniff for Firefox. At least, that is what
their server logs tell them.
David E. Ross
This is because many financial Web sites are developed by a very small
set of third-party contractors, Fiserv, Inc. and Goldleaf Technologies
being major players.
David E. Ross
I've had some small successes, not with E-mail but with postal mail to
the corporation's CEO.
Philip Chee
> Mike Beltzner schrieb:
> No, that's why I said "who cares" as I know that as much as it was
> thought to become potentially a good feature for evang efforts towards
> website, that never manifested (like so much in that area), and on our
> (Mozilla) side, nobody really cared too much about those reports, so
> nothing's really lost.
>
>> If you'd like to know how to migrate SeaMonkey to use this new feature, that's a pretty reasonable thing to ask!
>
> I won't believe that to be necessary unless I see this new effort to
> really work better then the last one.
>
> What I worry more about is us needing to do patches on our side when
> reporter gets removed. That should be nothing that is hard to do, just
> something we should know about.
I think getting the meeting minutes aggregator back on p.m.o. might go a
long way to alleviating what we in the corporate sector call "The Silo
Effect". I must admit that I've given up tracking a lot of things that I
should be since the meeting minutes disappeared from p.m.o. I've since
resorted to reading the pushlogs daily, however that only tells me of
things that have already landed then I have to hustle to fix breakages
over in SeaMonkey. See SeaMonkey Bug 570939 for example. OK so the fix
here was trivial, but a bit more heads up for more significant patches
might help in future. Looking over the comm-central pushlog (Includes
Thunderbird and Lightning/Sunbird) I see frequent checkins of the nature
"fix bustage due to mozilla-central changes to foobar". Frequently we
only find out when the Tinderboxen start burning. I'm sure that the
Thunderbird devs will tell you how often the TB tree has been closed in
a non-scheduled manner in the last few months.
Phil
--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
Philip Chee
The website doesn't care because they have outsourced website design to
some sweatshop in China.
Phil
--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
[ ]You gotta know when to hold 'em, know when to fold 'em.
* TagZilla 0.066.6
Justin Wood (Callek)
> Asa Dotzler wrote:
>> On 6/15/2010 2:27 PM, David E. Ross wrote:
>>
>>> Many, many responses in mozilla.support.seamonkey to queries about
>>> problems viewing Web sites -- especially invalid sniffing -- told users
>>> that they should go the [Help> Report a Broken Website]. Why, after so
>>> many years of such advice, are we only now learning that it was the
>>> wrong advice?
>>>
>>
>> Who in SeaMonkey land was telling you to tell users that. Perhaps that
>> person was doing something with those reports.
>>
>> - A
>
> I heard it as well from many of the experts the SeaMonkey.support Group.
> I think at one time even Chris I suggested it. May of the co-moderators
> at least once . For Myself I went several times to Report because it
> said in help menu :
> http://screencast.com/t/YTEzNzA5N.
>
> One assumes if *Report Broken Websites* is in help menu that is what you
> are supposed to do. had I known otherwise I would just reported in the
> SeaMonkey support to warn other of the problems.
>
I can't say I saw anyone of the SeaMonkey "team" telling users to
actively use that for help.
It more sounds like much of it was you assuming too much into a feature
and intent of the feature. Though I would be happy to be proven wrong
with links/message IDs of what Asa asked for.
--
~Justin Wood (Callek)
Axel Hecht
<...>
> But someone has to watch the data and do the outreach. I don't think
https://bugzilla.mozilla.org/show_bug.cgi?id=515171 is fun. A dozen+
sites that just return 50x error codes if you set your locale code to
"rm" (Romansh) (rm-CH doesn't work either in the ones I tested).
If anyone has a clue, jump in on that bug?
Thanks
Axel
Andrew Sutherland
> Frequently we
> only find out when the Tinderboxen start burning. I'm sure that the
> Thunderbird devs will tell you how often the TB tree has been closed in
> a non-scheduled manner in the last few months.
The actively developed Thunderbird branch has been building against
mozilla-1.9.2 until very recently and has not suffered from rogue tree
closures. The Thunderbird mozilla-central-based builders existed to
keep us abreast of changes in mozilla-central without burdening
mozilla-central developers; oranges/reds are an expected part of that
and a small price to pay for an actively developed upstream.
Now that Thunderbird is being actively developed against
mozilla-central, we are about to fork the comm-central mozilla-central
builders into two sets; one that builds only against known good (for
Thunderbird) mozilla-central revisions and one that acts as a canary
against the latest mozilla-central. The fact that we only have the
canary builder right now and that that can lead to tree closures is not
mozilla-central's problem or fault. Please see the discussion on the
tb-planning list for more information.
Andrew
Giacomo Magnini
> Note that all our messaging and branding around trunk builds is _designed_ to scare people away. I
> do think we should revisit that decision....
And this may be the only way to get the 3-4M testers Mozilla wants for FF4 instead of the usual 1M
(taken from l10n locale leaders email): nobody wants to test "Minefield", only "Firefox" is well known.
As a local community, we usually don't provide support for nightlies and/or prerelease versions, due
to the high amount of energy that we should put in such an effort. We might revise such policy to
help Mozilla for FF4, maybe electing a Mozilla Test Day once a week/every fortnight and ask for help
in the community, but we need a fully working browser, that is a browser which can surf as the
"release" version modulo bugs found, including banking & utilities sites, even the one sniffing
firefox UA.
Please help us help you guys.
Ciao, Giacomo.
Pavel Cvrcek
Dne 15.6.2010 2:33, Aakash Desai napsal(a):
> Unfortunately, while beginning to work on the second feat, I realized that there was **no one** actively maintaining or using the system on Firefox.
We (as Czech Mozilla Community) use Reporter. From time to time we look
at data which are available via http://reporter.mozilla.org/ and try to
find some relevant data for tech evanglism. But in reality the most of
data which goes from Reporter are irelevant. If I have a look at czech
sites (.cz) more than 90-95 % reports I must ignore because in these
reports users try to report different problems (they don't have proper
plugin etc.).
Regards,
--
Pavel Cvrček <pcv...@mozilla.cz>
http://www.mozilla.cz/
Axel Hecht
AFAICT, betas ship with official branding on, that is, they're called
Firefox proper.
No idea if we're going to rebrand the 'along-beta' nightlies like we did
on older branches. Might need a code name to begin with :-)
Axel
Mark Banner
> On 06/15/2010 10:41 PM, Philip Chee wrote:
>> Frequently we
>> only find out when the Tinderboxen start burning. I'm sure that the
>> Thunderbird devs will tell you how often the TB tree has been closed in
>> a non-scheduled manner in the last few months.
>
> The actively developed Thunderbird branch has been building against
> mozilla-1.9.2 until very recently and has not suffered from rogue tree
> closures. The Thunderbird mozilla-central-based builders existed to keep
> us abreast of changes in mozilla-central without burdening
> mozilla-central developers; oranges/reds are an expected part of that
> and a small price to pay for an actively developed upstream.
I'd also like to just clarify that the vast majority of bustages we've
had haven't been as a result of big changes or code removals in Firefox
land. The most frequent ones have been a result of our build system
being different to Firefox, and that isn't Firefox's fault. We are
actively thinking about ways of reducing those differences and I expect
they will start happening soon.
In fact, the only big change that I can remember causing us significant
bustage in the last few months was the add-on manager change, which we
did know was coming up, we just didn't have time to do any work before
it landed to resolve some of the issues.
In any case, what Andrew said about the canary system should help here.
I hope to be able to follow up on that in the next couple of days, to
get that moving forward.
Mark.
Philip Chee
> On 06/15/2010 10:41 PM, Philip Chee wrote:
>> Frequently we
>> only find out when the Tinderboxen start burning. I'm sure that the
>> Thunderbird devs will tell you how often the TB tree has been closed in
>> a non-scheduled manner in the last few months.
>
> The actively developed Thunderbird branch has been building against
> mozilla-1.9.2 until very recently and has not suffered from rogue tree
> closures. The Thunderbird mozilla-central-based builders existed to
> keep us abreast of changes in mozilla-central without burdening
> mozilla-central developers; oranges/reds are an expected part of that
> and a small price to pay for an actively developed upstream.
>
> Now that Thunderbird is being actively developed against
> mozilla-central, we are about to fork the comm-central mozilla-central
> builders into two sets; one that builds only against known good (for
> Thunderbird) mozilla-central revisions and one that acts as a canary
> against the latest mozilla-central. The fact that we only have the
Eeek! And the rational for that is?
> canary builder right now and that that can lead to tree closures is not
> mozilla-central's problem or fault. Please see the discussion on the
> tb-planning list for more information.
Newsgroup link please. I don't have time to subscribe to a bazillion
disparate mailing lists. I'm already suffering from information overload
trying to track changes in mozilla-central.
Phil
--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
[ ]I'm not confused, I'm just well-mixed.
* TagZilla 0.066.6
Philip Chee
> Boris Zbarsky wrote:
>> Note that all our messaging and branding around trunk builds is _designed_ to scare people away. I
>> do think we should revisit that decision....
>
> And this may be the only way to get the 3-4M testers Mozilla wants for FF4 instead of the usual 1M
> (taken from l10n locale leaders email): nobody wants to test "Minefield", only "Firefox" is well known.
Well Google has Chrome and Chromium. I suppose we could have Firefox
and, err, Firefoxen? FirefoxUnleashed? FirefoxGoesDingo?
Phil
--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
[ ]COBOL programmers understand why women hate periods.
* TagZilla 0.066.6
Giacomo Magnini
> No idea if we're going to rebrand the 'along-beta' nightlies like we did on older branches. Might
> need a code name to begin with :-)
Firefox NEXT?
I've already heard that... ;)
Ciao, Giacomo.
Phillip Jones
No it doesn't!
I complained to my Bank's website for two years and when the finally
made a change the choose to sniff on FireFox not Gecko. Up until my
coming over to SM 2 I had to either use UASwitcher or put the line in
the UA String "/not FireFox/x" x being the version number. Many sites
don't even have listed anywhere a place for an individual to to complain
to the webmaster. an individual has about as much impact on a web
Master as a gnat flying around their head. get a fly swatter and kill
the gnat.
The only way anyone listens is if a big organization calls them up
(such as Mozilla, MS, Opera, Omni) and show they have a problem.
You don't seem to understand this world we live in today. your still
stuck in 1970's, or 1980's beliefs. today all companies of any type,
care nothing about customers, other than long enough to get their money.
They no longer care about brand loyalty. so long as money has changed
hands. If they have the attitude such as that why do you think they
would pay attention to one person or even a 100 persons complaining
about their websites. Most corporate types don't even do their own web
design. they farm it out, and they don't want to complain to the
designer, because the designer can say okay its your pup now you fix it
I go some where else =where they will take my designs as they are.
The permanent cure is to make it so that sniffing does not work. you
should write code into FF and SM that ignores sniffing commands.
Phillip Jones
if it could be explained to Web designer to sniff on the word *Gecko*
not FireFox Or write something in SM that FF = Gecko we would have no
problems
Henri Sivonen
> I designed reporter to be sort of like talkback/breakpad, where we
> could
> collect and analyze *aggregate data* on websites that weren't working
> so
> we could either file bugs on Gecko if it was at fault, or maybe reach
> out to websites to try to get them to update their code if it was
> their
> fault.
If only aggregate data is of interest, then the new tool (contrary to the mockups) probably should
1) Not make sending the URL optional in the case of negative feedback.
2) Say that the reports are processed in the aggregate by URL first, so it's useless to type up stuff that the user would want people to read even if the URL doesn't raise a flag on the aggregate radar.
3) Not solicit positive feedback if it's going to /dev/null anyway.
--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/
David E. Ross
That is why I cite
<http://wiki.mozilla.org/User:Sardisson/Gecko_is_Gecko> when I complain
to a Web developer. I also cite the Bugzilla report by URI.
Robert Kaiser
> On 6/15/2010 6:30 PM, Robert Kaiser wrote:
>> Asa Dotzler schrieb:
>>> The days when we had to do labor-intensive outreach (at least in the
>>> West) to top 1000 sites are gone.
>>
>> That's true for having them work in Firefox, but not for Minefield or
>> SeaMonkey, as browser sniffing for the word "Firefox" in unfortunately
>> all too common nowadays. OTOH, I'm not sure if there's any good chance
>> to get hose fixed, esp. as even the .NET framework seems to do it, which
>> many people are using for constructing websites without knowing that
>> browser sniffing is even happening.
>
> website will go a lot further than user complaints to Mozilla.
In part of the cases, it actually helps - those websites tend to listen
to their users much more than to any 3rd party (like a browser vendor).
Also, my concept would make the sites work in the mean time by targeted
spoofing on the known-to-be-bad websites only. But that part currently
can't be implemented.
Robert Kaiser
--
Note that any statements of mine - no matter how passionate - are never
meant to be offensive but very often as food for thought or possible
arguments that we as a community needs answers to. And most of the time,
I even appreciate irony and fun! :)
Asa Dotzler
> Well Google has Chrome and Chromium. I suppose we could have Firefox
> and, err, Firefoxen? FirefoxUnleashed? FirefoxGoesDingo?
>
> Phil
>
This is somewhat wrong.
From what I can tell, Google doesn't just have Chrome and Chromium.
Google has Chrome Release (final releases,) Chrome Beta (beta releases
refreshed a couple times before finals,) and Chrome Developer (like
alphas that get refreshed every few days I think,) and then there's
Chromium (nightly builds.)
I think we should have Firefox Release, Firefox Beta, Firefox Alpha, and
Firefox Developer to be the equivalent channels.
We may still want to keep an unbranded channel around but I don't really
see the point.
- A
Asa Dotzler
> if it could be explained to Web designer to sniff on the word *Gecko*
> not FireFox Or write something in SM that FF = Gecko we would have no
> problems
>
Unless that web site doesn't want to offer to untested browsers.
Sniffing for Gecko alone means they might be endangering users who go
there with nightly or otherwise untested builds and experience serious
financial or privacy losses. Some sites might like to avoid that and the
way to do this is to test for Gecko plus a specific version that they've
tested against. As long as Seamonkey were using official Gecko
versions, this would probably work most of the time.
- A
Robert Kaiser
> As long as Seamonkey were using official Gecko versions,
> this would probably work most of the time.
And we do use official stable Gecko versions for our final releases.
Asa Dotzler
> The only way anyone listens is if a big organization calls them up (such
> as Mozilla, MS, Opera, Omni) and show they have a problem.
>
That's really not true. Millions, probably hundreds of millions of
Websites decided to start delivering content to Firefox without Mozilla
calling them up and showing them they have a problem.
> The permanent cure is to make it so that sniffing does not work. you
> should write code into FF and SM that ignores sniffing commands.
I think that's a fantasy. Once you block sniffing of user agents,
they'll move to capabilities that act as proxies (see document.all) and
then we'll have to start lying about support for these capabilities when
asked so as to avoid that sniffing (like we did in the exceptional case
of document.all). I think this is a genuine slippery slope.
What would you have sites do for Chrome and Safari which may both
contain Webkit (though different versions of Webkit) but contain
different JavaScript implementations, different networking stacks,
different storage mechanisms, different graphics stacks, etc. etc.
Sniffing on the string "webkit" is all kinds of fail. Toss in the
various mobile browsers based on Webkit and it's pretty much game over
for sniffing on engine name.
Mozilla isn't as fragmented, but there are several Geckos floating
around out there that don't behave the same. At a bare minimum, you'd
need version sniffing along with it. And you've still go the Trident and
Webkit problems. Oh, and Opera and Opera Mini and Mobile have both major
and minor differences in capabilities even though they're based on the
same core.
- A
Asa Dotzler
> Also, my concept would make the sites work in the mean time by targeted
> spoofing on the known-to-be-bad websites only. But that part currently
> can't be implemented.
Would you go the extra mile like Opera did and also ship a user.js that
tries to fix the broken sites that now let SeaMonkey in even though they
shouldn't because they aren't working quite right there the way they're
working in Firefox (because of version differences, etc.) ?
- A
Asa Dotzler
> Asa Dotzler schrieb:
>> As long as Seamonkey were using official Gecko versions,
>> this would probably work most of the time.
>
> And we do use official stable Gecko versions for our final releases.
>
> Robert Kaiser
Does Camino? If so, great. Less of a problem for Gecko. Still a huge
problem for WebKit and Presto.
- A
Tanner M. Young
> if it could be explained to Web designer to sniff on the word *Gecko*
> not FireFox Or write something in SM that FF = Gecko we would have no
> problems
There are cases like Safari and Chrome that say "like Gecko" which
breaks that. You can sniff for Webkit first, but that is something that
the web developer would need to know.
Tanner
Boris Zbarsky
> On 6/16/2010 7:30 AM, Phillip Jones wrote:
>> if it could be explained to Web designer to sniff on the word *Gecko*
>> not FireFox Or write something in SM that FF = Gecko we would have no
>> problems
>
> There are cases like Safari and Chrome that say "like Gecko" which
> breaks that.
Not if you sniff for "Gecko/" (which is what everyone who cares does as
a result).
-Boris
Daniel Veditz
> if it could be explained to Web designer to sniff on the word *Gecko*
> not FireFox Or write something in SM that FF = Gecko we would have no
> problems
We have had tech evangelism pushes around that. It apparently worked
to some extent since the Safari team found it useful to add "like
Gecko" to their user agent. Clearly that still left problems because
Gecko-containing SeaMonkey and Camino both have added "Firefox" to
their user agents.
It's sad they had to do it, reinforces the problem, bloats each and
every request, yadda yadda, but for their users it was the
pragmatically right thing to do.
Daniel Veditz
> The permanent cure is to make it so that sniffing does not work. you
> should write code into FF and SM that ignores sniffing commands.
The sniffing happens on the server side without any knowledge or
participation of the client; there's nothing for the client to
"ignore". The only way to "prevent" sniffing is to send such a
generic user agent string that we break every website that does any
at all. That would teach them! But it certainly would NOT fix the
complaint about incompatible nightlies/minefield versions, it would
just make the release Firefox builds just as bad. Then everyone
suffers for a couple of years as the sites are rewritten, assuming
they stick with Firefox.
It's really not a great plan.
Daniel Veditz
> "Report a web forgery" goes directly to Google and
> I can tell you that does not work, if the forger is a Google partner,
> maybe if they were phishing a bank it might get results.
They're certainly slow, but if you're not getting that to
work--especially if you think Google is not acting in good
faith--please send a mail with details to secu...@mozilla.org
-Dan Veditz
Phillip Jones
pre-decided, anyway not will happen other than Bad site reporting will
go away.
Robert Kaiser
> On 6/16/10 7:30 AM, Phillip Jones wrote:
>> if it could be explained to Web designer to sniff on the word *Gecko*
>> not FireFox Or write something in SM that FF = Gecko we would have no
>> problems
>
> We have had tech evangelism pushes around that. It apparently worked
> to some extent since the Safari team found it useful to add "like
> Gecko" to their user agent. Clearly that still left problems because
> Gecko-containing SeaMonkey and Camino both have added "Firefox" to
> their user agents.
Camino has, but SeaMonkey didn't (yet).
Robert Kaiser
For Camino, we'd need to ask their devs - but then, they have inflated
their UA with adding "Firefox" to it in any case, so I don't care about
this any more when it comes to them.
Robert Kaiser
That really depends on what is needed. In almost all cases I've heard so
far, the spoofing approach works - well enough that a number of people
are using a spoofed UA all the time, which I'd like to avoid by doing
that site-specific approach - but currently, docshell doesn't even let
us try doing it in any way.
Graham
> But someone has to watch the data and do the outreach. I don't think
> there's a big need for that for Firefox desktop, but SeaMonkey and other
> browsers, possibly Firefox Mobile, do still have lots more problems with
> site compatibility. There's no free lunch here. If you want to see this
> situation improve for SeaMonkey, give your time or find others to do it.
> To date, I don't think that's happened at all. Maybe a better tool will
> inspire more help in this area.
How about an easily accessible online display, automatically generated,
of the worst culprits with broken sites, the idea being to try to shame
them into compliance?
David E. Ross
A summary list of all browser sniffing bugs in bugzilla.mozilla.org is
at
<https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&field0-0-0=blocked&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&type0-0-0=equals&columnlist=changeddate,bug_severity,bug_status,resolution,short_short_desc&value0-0-0=334967>.
I'm sure some of the query portion of that URI is unnecessary, but I'm
not sure which can be removed.
Phillip Jones
> Daniel Veditz schrieb:
>> On 6/16/10 7:30 AM, Phillip Jones wrote:
>>> if it could be explained to Web designer to sniff on the word *Gecko*
>>> not FireFox Or write something in SM that FF = Gecko we would have no
>>> problems
>>
>> We have had tech evangelism pushes around that. It apparently worked
>> to some extent since the Safari team found it useful to add "like
>> Gecko" to their user agent. Clearly that still left problems because
>> Gecko-containing SeaMonkey and Camino both have added "Firefox" to
>> their user agents.
>
> Camino has, but SeaMonkey didn't (yet).
>
> Robert Kaiser
>
anyone see any reference to FireFox in this about SeaMonkey from my own
install.
http://screencast.com/t/N2I2MTZiNjkt