Closed
Bug 188449
Opened 23 years ago
Closed 13 years ago
Mach-O:Plugins don't get focus events
Categories
(Core Graveyard :: Plug-ins, defect)
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: jsb, Assigned: peterlubczynski-bugs)
Details
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3b) Gecko/20030104
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3b) Gecko/20030104
The Mach-O build is not sending getFocusEvent and loseFocusEvent events to
plugins.
As points of reference, those events are sent in each of the following:
The last CFM build I looked at (late-december)
Chimera (a recent build, like a few days ago)
Safari
These events are critical to our plugin (unfortunately, there are plenty of
other blockers that affect us, too)
Reproducible: Always
Steps to Reproduce:
1. Go to page with plugin
2. Click in plugin
Actual Results:
mouseDown/mouseUp events are sent to plugin correctly
Expected Results:
A getFocusEvent should be sent as well
Updated•23 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
| Reporter | ||
Comment 1•22 years ago
|
||
This remains a show-stopper for us. We haven't supported any build since 1.2.x
(that is, any Mach-O build) with our Macintosh plugins. There were several
reasons for that, but now that the new npruntime scripting enhancements are in
place, this bug moves toward the top of our list. Any thoughts of progress?
| Reporter | ||
Comment 2•21 years ago
|
||
Still no progress, still a show-stopper for us. I'm requesting that this be
considered for blocking1.8a6, in hopes that someone will at least look at this.
Please?
Flags: blocking1.8a6?
| Reporter | ||
Comment 3•21 years ago
|
||
Works properly in the 1.7.5 release build, but not in today's top-of-tree 1.8a6
build. Any chance the fix could be moved over, whatever it was?
Comment 4•21 years ago
|
||
Jonathan, can you identify the change that fixed this on the 1.7 branch? That
would probably go a long way towards getting it fixed on the trunk.
| Reporter | ||
Comment 5•21 years ago
|
||
Yeah, I know. I looked for a likely candidate by searching the codebase for "focus" and looking at the
commit messages, but I couldn't find one. Sorry. I was hoping that someone who had debuggable builds
of 1.7.5 and 1.8a on their machine could find the culprit pretty quickly. If that someone was familiar with
the code, they could put a breakpoint at the spot where the browser sends the focus event to the plugin in
1.7.5, and look at the backtrace. It should be easy after that, I hope -- something along that specific
backtrace isn't happening the same way in the 1.8a codebase...
Comment 6•21 years ago
|
||
Jonathan, another approach would be to test nightly builds from the branch and
see which day included the fix. Getting a one or two day window would probably
make the chage easily identifyable in bonsai.
<http://archive.mozilla.org/pub/mozilla/nightly/>
| Reporter | ||
Comment 7•21 years ago
|
||
Every build I can find that *wasn't* from the mainline seems to send the event properly (I tested back to
2003-09-16-15-1.5).
Every mainline build I can find (and I can't find that many, actually) fails to send the focus events at all.
The last mainline build that did send the focus events was prior to the CFM->MachO migration in 12/
2002 or so.
I don't know enough about the history of the source trees to know if that tells you anything.
Comment 8•21 years ago
|
||
Johnny, Simon, Pink, Brian, do any of you have any idea what's going on here? I
can't imagine how our release branches have this working but the trunk doesn't.
Comment 9•21 years ago
|
||
too late for non-critical fixes. blocking-
Flags: blocking1.8a6? → blocking1.8a6-
Updated•16 years ago
|
QA Contact: shrir → plugins
Updated•13 years ago
|
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
Updated•4 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•