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)
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)
2.24 KB,
text/plain
|
Details | |
6.58 KB,
patch
|
Details | Diff | Splinter Review |
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.
Assignee | ||
Comment 1•16 years ago
|
||
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.
Reporter | ||
Comment 2•16 years ago
|
||
Steven: I will work on trying to find another example as well as a regression range. I told you it was strange...
Assignee | ||
Comment 3•16 years ago
|
||
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.
Assignee | ||
Comment 4•16 years ago
|
||
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"
Reporter | ||
Comment 5•16 years ago
|
||
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.
Reporter | ||
Comment 6•16 years ago
|
||
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.
Assignee | ||
Comment 7•16 years ago
|
||
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.
Assignee | ||
Comment 8•16 years ago
|
||
This bug doesn't happen in today's Camino trunk nightly.
Assignee | ||
Comment 9•16 years ago
|
||
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?
Assignee | ||
Comment 10•16 years ago
|
||
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 :-(
Assignee | ||
Comment 11•16 years ago
|
||
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.
Assignee | ||
Comment 12•16 years ago
|
||
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 | ||
Updated•16 years ago
|
Assignee: nobody → smichaud
Flags: wanted1.9.0.x?
Priority: -- → P1
Assignee | ||
Comment 13•16 years ago
|
||
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
Assignee | ||
Comment 14•16 years ago
|
||
> 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.
Assignee | ||
Comment 16•16 years ago
|
||
Bug 454104 has significant additional information, and a better example.
Comment 17•16 years ago
|
||
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-
Assignee | ||
Comment 18•15 years ago
|
||
Fixed by patch for bug 476393.
Comment 19•15 years ago
|
||
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
Keywords: fixed1.9.1 → verified1.9.1
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.
Description
•