374044 - displayed image tears when user mouses across a different widget on the page

Status: RESOLVED WORKSFORME

(SeaMonkey :: General, defect)

Description

[Kent Paul Dolan]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a3pre) Gecko/20070313 SeaMonkey/1.5a
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a3pre) Gecko/20070313 SeaMonkey/1.5a

[This has been ongoing for weeks, is maddening because the
effect is usually "just barely seen". The reference URL is
a very visible and reproducable example of the problem.]

When an image is displayed with a bunch of active widgets
under it, the image sometimes tears (a rectangular sub-block
of it gets shifted sideways) when the user mouses over one
of those active widgets.

In the existing case, display the page, then bring the mouse
from the bottom of the screen across the drop down menu
with displayed default entry "plot point". The comic image
above with develop a very visible tear in one of the vertical
black gutter lines in the center not far from the bottom of
the comic. The image, if "reload" is clicked, will become
intact, and the mouse over, tear image, and reload cycle can
be done as many times as desired.

xanthian.


Reproducible: Always

Steps to Reproduce:
1. Open URL
2. Mouse over "plot point" menu from below.
3. Watch displayed comic image tear.
Actual Results:  
Image tears, usually seen as a "jump" out of the corner
of the eye.

Expected Results:  
Mousing over a widget should not disrupt other
parts of the display.

This is an extremely widespread problem, seen on many
pages with a mix of images and active widgets, but
few times as visible as in this case.

Marking as "major" because there is an inappropriate
interaction between mouse motion and parts of the
displayed data not even under the mouse, suggesting
software crosstalk is happening, which could cause
many other very visually different symptoms from the
same basic problem. This version is easy to
troubleshoot, so doing so may help cure many reported
bugs at once, suggesting it receive an early look.

xanthian.

Comment 1

[Kent Paul Dolan]

This is almost certainly the same bug:

http://www.weather.com/weather/map/85281?clip=710&region=null&collection=localwxforecast&presname=Tempe,%20AZ%20Forecast&name=index_large_animated&day=1

With the weather radar map in motion,
mousing over the "doppler radar 600 mile"
menu creates a one pixel wide white vertical
tear half the height of the radar image and
aligned with the left edge of the radar menu.

xanthian.

Comment 2

[Wayne Mery (:wsmwk)]

NTF for both URLs
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a4pre) Gecko/20070330 SeaMonkey/1.5a

perhaps related to your combo of mouse/video
fwiw, the map image is .jpg

Comment 3

[Kent Paul Dolan]

(In reply to comment #2)
> NTF for both URLs

Private acronyms may work to communicate among developers,
but if you expect bug reporters to read what you write,
spell it out.

> Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a4pre) Gecko/20070330
> SeaMonkey/1.5a

> perhaps related to your combo of mouse/video

No, not a video problem, since the problem is
window coordinate specific, not screen coordinate
specific. If the window is moved, the problem
continues to line up with the dropdown menu edge
in that window. If the problem were a video problem,
the video device is ignorant of the window internal
structure, so it couldn't replicate the problem
independent of the window location.

No, not a mouse specific problem, my laptop has
a built-in touchpad mouse, and I've added a USB
laser mouse. The problem is the same with either.

> fwiw, the map image is .jpg

It's worth nothing at all if your first approach
is to try to put the error anywhere but in the
SeaMonkey code.

xanthian, with 46 years experience dealing with
software development blameshifters.

Comment 4

[Wayne Mery (:wsmwk)]

(In reply to comment #3)
> (In reply to comment #2)
> > NTF for both URLs
> Private acronyms may work to communicate among developers,
> but if you expect bug reporters to read what you write,
> spell it out.

google "NTF acronym" would get have gotten you the answer faster than you could have typed the retort


> xanthian, with 46 years experience dealing with
> software development blameshifters.

in that case, good luck

Comment 5

[Kent Paul Dolan]

(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> > > NTF for both URLs
> > Private acronyms may work to communicate among developers,
> > but if you expect bug reporters to read what you write,
> > spell it out.\

> google "NTF acronym" would get have gotten
> you the answer faster than you could
> have typed the retort

  [Apparently you have no business working in the
  field of software development, as you lack the
  needed grounding in how and where problems are
  supposed to e solved.]

Sure, but that inappropriately fixes the problem
at the fanned out end, and on a recipient by
recipient basis, where a fix at the source of
the problem, by teaching you better bugzilla
writing habits, solves the problem once and for
all, well worth the comment writing effort for
someone who can type as fast as I do.

I notice, information gathered already from the
abundant evidence you choose to provide, that you
are a slow learner, as you preferred to give a
snotty response and prolong the inconvenience,
rather than explain your acronym in your reply.

Your answer was non-responsive to the need.

Do try again.

xanthian, trying to teach a brick to think is
fun, fun, fun.

Comment 6

[Wayne Mery (:wsmwk)]

also WFM, two different systems and video
* Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.2) Gecko/20070222 SeaMonkey/1.1.1 XpcomViewer/0.8.9
* Build identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a8pre) Gecko/2007091102 SeaMonkey/2.0a1pre

what video chip and version of driver are you using?

Comment 7

[Wayne Mery (:wsmwk)]

no response. still WFM : Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9pre) Gecko/2008042302 SeaMonkey/2.0a1pre
so => WFM