Closed Bug 431902 Opened 16 years ago Closed 15 years ago

Loading this site causes text highlight to move the Firefox window

Categories

(Core :: Widget: Cocoa, defect, P1)

All
macOS
defect

Tracking

()

VERIFIED FIXED
mozilla1.9.2a1

People

(Reporter: marcia, Assigned: smichaud)

References

()

Details

(Keywords: verified1.9.1, Whiteboard: [fixed by bug 476393])

Attachments

(2 files)

Seen using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008050209 Minefield/3.0pre.

1. Fresh profile, open 3-4 tabs including a tab with the URL.
2. After the Visual Thesaurus site loads, type something in the search and click "Look it Up."  Some type of app launches and I click "Try". Keep that app running.
3. Using your mouse, move to an adjacent tab.
4. Place your mouse in the URL bar and try to copy and paste the text.

Actual: Suddenly anytime I place my cursor in the URL bar a drag window event starts and my whole Firefox window starts moving any time I put my mouse in the URL bar. I cannot easily copy and paste any URL. Even when I move my mouse in web pages to try to highlight text the window starts to move, or when I place my mouse on the scroll bar the window begins to move as I move my mouse.

Note that I am not able to repro this on Tiger with the same steps.
Bizarre.  Now I _am_ able to reproduce this problem.  So far I've only
tried on Leopard.

The thing that runs in step 2 _is_ a Java applet -- one that runs in a
separate window.  The problem doesn't happen with Firefox 2.0.0.14.

You don't need to have more than one tab open to see wierdness, and it
continues after the applet window has been closed.  In particular,
every drag operation moves the window.  So (for example) when you try
to scroll the window with the scrollbar, the window moves instead.

These problems don't happen in a new window.  But they keep happening
in the original window until you close it.

If possible, we need to establish a regression range.

We also need to find another example of a Java applet that opens its
own window, and see if that also triggers this bug.
Steven: I will work on trying to find another example as well as a regression range. I told you it was strange...
This problem wasn't introduced by Apple's recent "Java for Mac OS X
10.5, Update 1" -- I also see the problem on an OS X 10.5.2 partition
whose Java hasn't been updated.

It doesn't happen in Safari.
This problem isn't triggered by every Java applet that opens its own
window.  Here are two examples:

1) http://www.lohn1.de/lobn.htm

   To open the Java applet window, click on the "berechnen" button.

2) http://www.sferyx.com/htmleditorapplet/demo/htmleditordemowindow.htm

   Click on "Start Visual Editor"
I checked Vista just to be sure it is not a cross platform issue, and Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9pre) Gecko/2008050206 Minefield/3.0pre works fine with that site.
This bug exists for sure in FF B1, Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b1) Gecko/2007110903 Firefox/3.0b1. I will need to travel back further in history to see how long it has been present.
Once this bug's URL's Java applet window is open, you start seeing
repetitions of the following error in the system console:

*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug

These happen in system code, and appear to be the result of trying to
malloc an impossibly large "region".

The attachment is a stack trace made at one of these errors.  To see
one for yourself, break on malloc_printf in gdb.
This bug doesn't happen in today's Camino trunk nightly.
Here's a hunch (or even a wild guess) -- Maybe the basic problem is
that Minefield can't deal with a Java applet in a form (or a div).

This comes from something that Matthew Gregan said at bug 277067
comment #130.  Matthew, what do you think?  Do you have the same
problems loading applets into divs on trunk Camino that you do on
trunk Minefield?
Like Marcia I don't see this bug on Windows (with today's nightly) or
OS X 10.4.11 (with a nightly from early April).  I also don't see it
on Linux (with today's nightly).

> Maybe the basic problem is that Minefield can't deal with a Java
> applet in a form (or a div).

I think my wild guess was probably wrong :-(
The Java applet window usually ends up closing spontaneously --
possibly as a result of errors.  But the "can't allocate region"
malloc errors continue after this has happened.  I find the easiest
way to trigger them is to resize the browser window from which the
Java applet was spawned.

These errors don't happen resizing another browser window (one you
opened after loading the Java applet) -- even if it has exactly the
same contents as the first one.
This bug seems to be related to bug 432743 (which also triggers the
wierd malloc error).  And I suspect both belong in Core : Plug-ins.
Component: Location Bar and Autocomplete → Plug-ins
Product: Firefox → Core
QA Contact: location.bar → plugins
Assignee: nobody → smichaud
Flags: wanted1.9.0.x?
Priority: -- → P1
Attached patch Provisional fixSplinter Review
I'm only able to reproduce this problem on OS X 10.5.2 (not on
10.4.11).

And I've found a way to get rid of the "can't allocate region"
messages which also fixes this bug.  But my patch (my workaround)
doesn't really get at the heart of the problem (whatever that is), so
I hope to do better at some point in the future.

If this problem becomes urgent (which it currently isn't), I'm pretty
sure it'd be safe to land this patch.  But until/unless that happens
I'd like to keep working on it.

The strangeness of the problem and the fact that it only happens on
Leopard suggest that it's caused by an OS bug.  But the browser might
be doing something to trigger it ... or the JEP might be.

Here's a tryserver build made with my provisional patch:

https://build.mozilla.org/tryserver-builds/2008-05-21_15:33-smichaud@pobox.com-bugzilla431902/smichaud@pobox.com-bugzilla431902-firefox-try-mac.dmg
> This bug seems to be related to bug 432743 (which also triggers the
> wierd malloc error).

If it's related, it's only very distantly related.

My patch (from comment #13) gets rid of the "can't allocate region"
messages at bug 432743, but doesn't fix that bug's crash.
Bug 454104 has significant additional information, and a better example.
Doesn't really meet the "wanted" criteria (security, stability, regression from maintenance release) for 1.9.0.x. However, we'll look at a reviewed and baked patch.
Flags: wanted1.9.0.x? → wanted1.9.0.x-
Fixed by patch for bug 476393.
Status: NEW → RESOLVED
Closed: 15 years ago
Keywords: fixed1.9.1
Resolution: --- → FIXED
Verified fixed on trunk and 1.9.1 branch with:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090208 Minefield/3.2a1pre

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090208 Shiretoko/3.1b3pre
Status: RESOLVED → VERIFIED
Component: Plug-ins → Widget: Cocoa
Depends on: 476393
QA Contact: plugins → cocoa
Hardware: x86 → All
Whiteboard: [fixed by bug 476393]
Target Milestone: --- → mozilla1.9.2a1
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: