DoS Issue With Phoenix.edu ???

classic Classic list List threaded Threaded
14 messages Options
JWS
Reply | Threaded
Open this post in threaded view
|

DoS Issue With Phoenix.edu ???

JWS
I ran into a rather odd problem over the weekend:

My wife attends phoenix.edu & when attempting to log into class with
Firefox, the browser appeared to hang, with the words "Updating Site
Cookie" in the title of the page.  At that point the CPU load from
Firefox went up to ~90% and the page status in the bottom left would
blink between "waiting on phoenix.edu" & "Done", but the login page
never loaded.  Her sw load has not changed in months, short of the
inevitable XP & Java updates.  I moved her to Exploder & she was able
to get into class.  The next AM Exploder had the exact same "Updating
Site Cookie" problem & I was unable to correct it by removing &
reinstalling Java & Foxfire.  Sooooo, I moved her to another system,
where she was able to do her school work with Foxfire.  The next AM we
had the exact same "Updating Site Cookie" problem with Foxfire & had
to move her to Exploder.  At last check Exploder was still working.

I run AVG Internet Security Suite & SpyWare Terminator on both systems
& the scans run clean.

Ideas?
Needless to say, the tech support guys @ Phoenix were no help.  ;-)

THX!

JWS
_______________________________________________
dev-quality mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-quality
Reply | Threaded
Open this post in threaded view
|

Re: DoS Issue With Phoenix.edu ???

Tim Riley-3
JWS,

What version of Firefox are you using?  Have you tried the brand new
Firefox 3.5?

Are cookies enabled in Firefox preferences?

Given that is intermittent on both Firefox and IE, I wonder if it is
something with your network or the server.

One place to get more support is http://www.mozilla.org/support/ .
Particularly, see the knowledge base or community support forums.

--Tim

On 6/29/09 9:17 AM, JWS wrote:

> I ran into a rather odd problem over the weekend:
>
> My wife attends phoenix.edu&  when attempting to log into class with
> Firefox, the browser appeared to hang, with the words "Updating Site
> Cookie" in the title of the page.  At that point the CPU load from
> Firefox went up to ~90% and the page status in the bottom left would
> blink between "waiting on phoenix.edu"&  "Done", but the login page
> never loaded.  Her sw load has not changed in months, short of the
> inevitable XP&  Java updates.  I moved her to Exploder&  she was able
> to get into class.  The next AM Exploder had the exact same "Updating
> Site Cookie" problem&  I was unable to correct it by removing&
> reinstalling Java&  Foxfire.  Sooooo, I moved her to another system,
> where she was able to do her school work with Foxfire.  The next AM we
> had the exact same "Updating Site Cookie" problem with Foxfire&  had
> to move her to Exploder.  At last check Exploder was still working.
>
> I run AVG Internet Security Suite&  SpyWare Terminator on both systems
> &  the scans run clean.
>
> Ideas?
> Needless to say, the tech support guys @ Phoenix were no help.  ;-)
>
> THX!
>
> JWS

_______________________________________________
dev-quality mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-quality
Reply | Threaded
Open this post in threaded view
|

Re: Triage for Extension Issues

Tanner M. Young
Clint,

I really like the idea.  It should reduce a lot of confusion and act as a
pipeline between Mozilla and the Add-on developers.

Tanner Young

"Clint Talbert" <[hidden email]> wrote in message
news:[hidden email]...

> Hi Quality People,
>
> Currently when we find a bug that is in an extension we mark it as
> 'invalid'.  I think that is the right approach w.r.t. bugzilla, but it
> has the negative problem that this issue is now essentially untrackable
> in bugzilla.  It would be far more useful to move these bugs into a
> queue that the Add-Ons team can then use to drive fixes to popular
> extensions.
>
> We have an "extension compatibility" component in the Firefox Bugzilla
> Product.  So, I propose that we do the following when we encounter a bug
> in an extension:
>
> * Triage the bug as being in an extension (try to reproduce, reproduce
> in safe mode, determine which extension is causing the problem).
> * Move the bug to the Firefox->Extension Compatibility area
> * Leave the bug open and put in a comment that the AMO reviewers/editors
> will take this up with the developer of the extension (if possible).
>
> How does that sound?
>
> Clint
> _______________________________________________
> dev-quality mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-quality


_______________________________________________
dev-quality mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-quality
Reply | Threaded
Open this post in threaded view
|

Re: Triage for Extension Issues

Henrik Skupin-3
Tanner Young wrote on 01.07.09 23:59:

> I really like the idea.  It should reduce a lot of confusion and act as a
> pipeline between Mozilla and the Add-on developers.

I like it too. That will make it easier to find dupes. I vote for it.

Henrik


_______________________________________________
dev-quality mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-quality
Reply | Threaded
Open this post in threaded view
|

Re: Triage for Extension Issues

Kevin Brosnan
The worry I have is that this will be an unowned component like tech
evangelism. For this to succeed this needs to have active
participation from the extension developers and the AMO reviewers. We
need to avoid a bug in an unclear state.

When should an extension compatibility bug go from unco > new?
"           "  new to fixed/incomplete/assigned/invalid/wontfix

AMO extension reviewers are already overworked has anyone talked to
them about this change in process.

The original purpose of this component was for popular amo extensions
that were version incomparable with the current/upcoming Firefox
release to be tracked. Not for general issues with extension xyz. It
would be good to check with the owner of the component before morphing
its meaning.


On Wed, Jul 1, 2009 at 20:13, Henrik Skupin<[hidden email]> wrote:

> Tanner Young wrote on 01.07.09 23:59:
>
>> I really like the idea.  It should reduce a lot of confusion and act as a
>> pipeline between Mozilla and the Add-on developers.
>
> I like it too. That will make it easier to find dupes. I vote for it.
>
> Henrik
>
>
> _______________________________________________
> dev-quality mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-quality
>
_______________________________________________
dev-quality mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-quality
Reply | Threaded
Open this post in threaded view
|

Re: Triage for Extension Issues

Kevin Brosnan
Forgot to say in general I like the idea of following extension issues.

On Wed, Jul 1, 2009 at 20:51, Kevin Brosnan<[hidden email]> wrote:

> The worry I have is that this will be an unowned component like tech
> evangelism. For this to succeed this needs to have active
> participation from the extension developers and the AMO reviewers. We
> need to avoid a bug in an unclear state.
>
> When should an extension compatibility bug go from unco > new?
> "           "  new to fixed/incomplete/assigned/invalid/wontfix
>
> AMO extension reviewers are already overworked has anyone talked to
> them about this change in process.
>
> The original purpose of this component was for popular amo extensions
> that were version incomparable with the current/upcoming Firefox
> release to be tracked. Not for general issues with extension xyz. It
> would be good to check with the owner of the component before morphing
> its meaning.
>
>
_______________________________________________
dev-quality mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-quality
Reply | Threaded
Open this post in threaded view
|

Re: Triage for Extension Issues

Clint Talbert-3
In reply to this post by Henrik Skupin-3
On 7/1/09 5:51 PM, Kevin Brosnan wrote:
> The worry I have is that this will be an unowned component like tech
> evangelism. For this to succeed this needs to have active
> participation from the extension developers and the AMO reviewers. We
> need to avoid a bug in an unclear state.
>
+1, I'm all for ideas on how to help that.  Ideally, I'd like the
extension developers to know about this and they could use it to find
issues in their own extensions, but I'm also an eternal optimist. :)

> When should an extension compatibility bug go from unco>  new?
> "           "  new to fixed/incomplete/assigned/invalid/wontfix
>
> AMO extension reviewers are already overworked has anyone talked to
> them about this change in process.
>
I copied Nick on this, but he hasn't jumped in yet.  I might follow up
with him tomorrow in RL.  Does anyone know if there is a AMO mailing
list I should have copied with this proposal?

> The original purpose of this component was for popular amo extensions
> that were version incomparable with the current/upcoming Firefox
> release to be tracked. Not for general issues with extension xyz. It
> would be good to check with the owner of the component before morphing
> its meaning.
>
Yes, true.  I'll follow up with them - not sure who the component owner
actually is.  The other thing that I have been thinking about is that
even if we start moving items over here, we still don't have an easy way
of answering the query "what problems are there with extension xxx?".
For that we might want to prepend the summary with the extension name:
"[QAC Issue] My tabs all disappeared and I don't know why" (for a
summary talking about the QAC extension.  Or perhaps a whiteboard flag
could be used...I haven't decided yet.  The summary is inifintely more
queryable for people new to bugzilla than the whiteboard flag.

Thanks for your thoughts.

Clint
_______________________________________________
dev-quality mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-quality
Reply | Threaded
Open this post in threaded view
|

Re: Triage for Extension Issues

Henrik Skupin-3
Clint Talbert wrote on 02.07.09 10:04:

> Yes, true.  I'll follow up with them - not sure who the component owner
> actually is.  The other thing that I have been thinking about is that
> even if we start moving items over here, we still don't have an easy way
> of answering the query "what problems are there with extension xxx?".
> For that we might want to prepend the summary with the extension name:
> "[QAC Issue] My tabs all disappeared and I don't know why" (for a
> summary talking about the QAC extension.  Or perhaps a whiteboard flag
> could be used...I haven't decided yet.  The summary is inifintely more
> queryable for people new to bugzilla than the whiteboard flag.

And it's kinda harder for crashing or hanging bugs. We should not move
them into this component as long we aren't sure it is really an
extension problem. I have a good example here which covers a crash with
the Noia 2 (Extreme) theme but is a widget issue.

https://bugzilla.mozilla.org/show_bug.cgi?id=490196

Henrik
_______________________________________________
dev-quality mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-quality
Reply | Threaded
Open this post in threaded view
|

Re: Triage for Extension Issues

Tanner M. Young
> And it's kinda harder for crashing or hanging bugs. We should not move
> them into this component as long we aren't sure it is really an
> extension problem. I have a good example here which covers a crash with
> the Noia 2 (Extreme) theme but is a widget issue.

That is a problem.

Also, I don't know how the AMO community will respond; it is an extremely
diverse group of developers, each already having their own support and
development strategies.  Having said that, the AMO team is trying to make
add-ons and add-on development more consistent, so this could be the perfect
time.

If we implement this, ultimately, we could create an integration tool
between AMO and BMO, allowing users to report add-on issues directly in AMO.

Another concern would be that this could overwhelm BMO or create a lot of
bug spam.  We might want a separate Bugzilla install for this.  If we did
that, theoretically, we could share usernames and passwords between BMO and
this new "ABMO."  And we could have it create components for new add-ons
dynamically.  This would reduce that management that Mozilla would need to
do, but it could also simply become a large bug landfill.  If we want, I can
check with Gerv, LpSolit, etc. and see how something like this flies, but I
don't know if Bugzilla could even handle 9,095 components to begin with.

Tanner


_______________________________________________
dev-quality mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-quality
Reply | Threaded
Open this post in threaded view
|

Re: Triage for Extension Issues

Clint Talbert-3
In reply to this post by Henrik Skupin-3
On 7/2/09 7:33 AM, Tanner Young wrote:>
> Another concern would be that this could overwhelm BMO or create a lot of
> bug spam.  We might want a separate Bugzilla install for this.  If we did
> that, theoretically, we could share usernames and passwords between BMO and
> this new "ABMO."  And we could have it create components for new add-ons
> dynamically.  This would reduce that management that Mozilla would need to
> do, but it could also simply become a large bug landfill.  If we want, I can
> check with Gerv, LpSolit, etc. and see how something like this flies, but I
> don't know if Bugzilla could even handle 9,095 components to begin with.

Woah, I admire your spirit, but you're off to boil the ocean.  It seems
to me that you're suddenly talking about using Bugzilla to manage the
entire Add-Ons ecosystem, which is much much bigger than what I'm
proposing.  I just want to find a way that we can easily track user
reported extension related issues.

In particular, I want to solve the problem where people report a bug
against Firefox, we determine that said bug is actually a problem in
extension X and close the bug invalid.

There is absolutely no way for the AMO folks or for an interested
extension developer to find those bugs, and it is never clear if that
extension developer gets a notice about the issue (we always ask
reporters to notify extension developers, but we have no way to know if
that happens).


I want to solve this first little hole in our triage process before we
try to massively impose bmo on amo.

Clint



_______________________________________________
dev-quality mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-quality
Reply | Threaded
Open this post in threaded view
|

Re: Triage for Extension Issues

Tanner M. Young
In reply to this post by Tanner M. Young
> Woah, I admire your spirit, but you're off to boil the ocean.  It seems
> to me that you're suddenly talking about using Bugzilla to manage the
> entire Add-Ons ecosystem, which is much much bigger than what I'm
> proposing.  I just want to find a way that we can easily track user
> reported extension related issues.

I wouldn't want to do it myself (the ocean boiling would be something of an
understatment), but that could be what this turns into, and most wild and
crazy ideas are worth mentioning, even if it's for a good laugh :).

> In particular, I want to solve the problem where people report a bug
> against Firefox, we determine that said bug is actually a problem in
> extension X and close the bug invalid.

My primary fear is that the developers still wont get notified since the new
extension component is for all 9,000 extensions, so we could have same
problem.  If I am wrong, please correct me.

> There is absolutely no way for the AMO folks or for an interested
> extension developer to find those bugs, and it is never clear if that
> extension developer gets a notice about the issue (we always ask
> reporters to notify extension developers, but we have no way to know if
> that happens).
>
> I want to solve this first little hole in our triage process before we
> try to massively impose bmo on amo.

I still like the idea, and if this is the best way to do this or the best
way to do this for the moment, I would go ahead with it.

Tanner


_______________________________________________
dev-quality mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-quality


_______________________________________________
dev-quality mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-quality
Reply | Threaded
Open this post in threaded view
|

Re: Triage for Extension Issues

Tanner M. Young
> Clint, your proposed solution is better than what we have, but I agree
> with Andrew that the problem is getting add-on devs to look in Bugzilla.
> Most have their own feedback mechanisms in places like Mozdev, Google
> Code, and plain ol' email.
>
> One solution might be to put a 'Query bugs' link somewhere in the AMO
> Developer Panel that does a bug lookup for their particular add-on, but
> that does not cover add-ons not hosted on AMO.
>
> --
> Brian King

I like the suggestion of integrating AMO and BMO (or another Bugzilla
install) as an end-solution.  For the moment I think we should go with
Clint's suggestion for triaging, organizing, and isolating the bugs we have,
and then we can impliment a more holistic solution.

At this point in designing our solution, I think we would be best served by
drafting a phased-implimentation plan in the wiki that can be reviewed by
the QA, AMO, and WebDev teams.

Tanner


_______________________________________________
dev-quality mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-quality
Reply | Threaded
Open this post in threaded view
|

Re: Triage for Extension Issues

Smokey Ardisson
In reply to this post by Clint Talbert-3
On Jul 2, 2:31 pm, Clint Talbert <[hidden email]> wrote:

> There is absolutely no way for the AMO folks or for an interested
> extension developer to find those bugs, and it is never clear if that
> extension developer gets a notice about the issue (we always ask
> reporters to notify extension developers, but we have no way to know if
> that happens).

Since Bugzilla can create a feed from an arbitrary query, I wonder if
you could ask AMO to embed the feed in the extension developer's
dashboard (or whatever) on AMO, perhaps also adding links for the
queries themselves so those that are really attentive could run them
manually.

Note: I really know nothing about the AMO or extension developers
beyond what I sort-of skim on planet occasionally, so this proposal
assumes that extension developers regularly monitor their dashboard or
whatever it is on AMO (e.g., stats).  The other thing that it presumes
is some sort of standard naming practice when you triage the bugs so
that the query will pick them up and so that there can be automatic
(via regexp or other transformation) association on AMO, and that this
can in fact be coded into AMO (and all the feeds won't impose a perf
strain on bmo).

This could work for any component or triage method you wanted to use
(you could even continue to mark the bugs INVALID and leave them
wherever in the Firefox product, though that may hinder human tracking
and make it harder to assess the overall picture than a component with
all the open issues), assuming you do the standard naming bit.

It still won't guarantee that extension devs see the issues recorded
in bmo, but it's a possibility.

(Here ends my crazy idea of the day on a topic far afield of my normal
QA work ;-) )

Smokey
_______________________________________________
dev-quality mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-quality
Reply | Threaded
Open this post in threaded view
|

Re: Triage for Extension Issues

Martijn-4
In reply to this post by Henrik Skupin-3
2009/7/2 Henrik Skupin <[hidden email]>:

> Clint Talbert wrote on 02.07.09 10:04:
>
>> Yes, true.  I'll follow up with them - not sure who the component owner
>> actually is.  The other thing that I have been thinking about is that
>> even if we start moving items over here, we still don't have an easy way
>> of answering the query "what problems are there with extension xxx?".
>> For that we might want to prepend the summary with the extension name:
>> "[QAC Issue] My tabs all disappeared and I don't know why" (for a
>> summary talking about the QAC extension.  Or perhaps a whiteboard flag
>> could be used...I haven't decided yet.  The summary is inifintely more
>> queryable for people new to bugzilla than the whiteboard flag.
>
> And it's kinda harder for crashing or hanging bugs. We should not move
> them into this component as long we aren't sure it is really an
> extension problem. I have a good example here which covers a crash with
> the Noia 2 (Extreme) theme but is a widget issue.
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=490196

In those cases, there might be 2 bugs, one bug in Mozilla where it
crashes when some (invalid) xpcom code is.
As I understand it, Mozilla should never crash on any xpcom code at
all, that is called from js.
When this happens, though, the extension code is probably also doing
something wrong, since clearly something happened which the code in
the extension didn't account for.

If it's a binary extension and the crash happens in there, then the
extension is entirely to blame.
When a theme is causing Mozilla to crash, then it's most likely
Mozilla to blame.

Regards,
Martijn


> Henrik
> _______________________________________________
> dev-quality mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-quality
>



--
Martijn Wargers - Help Mozilla!
http://quality.mozilla.org/
http://wiki.mozilla.org/Mozilla_QA_Community
irc://irc.mozilla.org/qa - /nick mw22
_______________________________________________
dev-quality mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-quality