Sort out the Talkback Client issue on Intel Macs

RESOLVED FIXED

Status

Core Graveyard
Talkback Client
--
major
RESOLVED FIXED
12 years ago
8 years ago

People

(Reporter: mano, Assigned: preed)

Tracking

({fixed1.8.0.2, fixed1.8.1})

Trunk
PowerPC
Mac OS X
fixed1.8.0.2, fixed1.8.1
Bug Flags:
blocking1.8.1 +
blocking1.8.0.2 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

Since we don't have its source code, mactel builds aren't going to have a
working talkback client.

Comment 1

12 years ago
Talkback also seems to be unable to get a stack trace when tracing a PPC build
running on intel (under Rosetta).

Comment 2

12 years ago
Dependant on Bug 216827?
....
<josh>	Mano: we have decided to ship 1.5.0.2 Intel with no talkback
...
<josh> if possible we will enable talkback for PPC and include PPC-only talkback with the app
<josh> should be possible
<josh> if possible we will enable talkback for PPC and include PPC-only talkback with the app
Flags: blocking1.8.1?
When sorting this out ;) it would be good to also fix bug 315616, bug 187107, bug 244672 (Camino's Talkback still calls the app "Mozilla"), and at least look at bug 295976 (which maybe can't be fixed at all)--not only for Intel but also for PPC.
*** Bug 331280 has been marked as a duplicate of this bug. ***
nominating for 1.8.0.[23] blocking, so we'll remember to discuss this in the release team meeting.

Right now, Firefox running under rosetta on an intel mac does not crash; instead, it hangs with spinning beachball.

steps to reproduce: start firefox, then send firefox-bin process SEGV signal
Status: NEW → ASSIGNED
Flags: blocking1.8.0.3?
Flags: blocking1.8.0.2?

Comment 7

11 years ago
I had initially written this as a comment to go along with duping 331280 to here, but davel managed to catch the dupe first.

From what I understand, you guys (Moz) do have something worked out to port Talkback internally, but this might not get any real traction until something like  bug 216827, where I'm also on the case.

Talkback under Rosetta will never work, period.  One easy thing I can recommend is checking to see if the app is running under Rosetta and NOT installing the signal handlers if it is.  I can't touch or look at Talkback source because I don't have a license, but this should be a simple change to make.  The Rosetta check is simple, here's an example:

#include <sys/sysctl.h>

int isNative = 0;
size_t sz = sizeof(isNative);
if (sysctlbyname("sysctl.proc_native", &isNative, &sz, NULL, 0) != 0 ||
    isNative) {
  // running natively (not translated)
  // if the sysctl failed, it doesn't exist, so the app must be running native
  // if the sysctl succeeded, check isNative
}
blocking1.8.0.2+ for drivers, as per email and irc discussions.  Josh is working on the patch to disable talkback if firefox is running under rosetta (on x86 mac).
Assignee: jay → joshmoz
Status: ASSIGNED → NEW
Flags: blocking1.8.0.3?
Flags: blocking1.8.0.2?
Flags: blocking1.8.0.2+

Comment 9

11 years ago
I have a patch, but I don't think I can post it publicly as it is against talkback glue code. I'm still testing it.
Flags: blocking1.8.0.2+ → blocking1.8.0.2?
Hi Josh,

I'm confused - why did you revert this bug to blocking? from blocking+?  My understanding of the blocking flag is that it indicates we are holding the release for the resolution of this bug.

To all - What have we done with talkback patches in the past, if we could not post them in bugzilla open bugs?

Comment 11

11 years ago
I didn't mean to revert the blocking flag - my browser must have messed it up when I reloaded the page to post my comment.
restoring blocking+ flag
Flags: blocking1.8.0.2? → blocking1.8.0.2+
removing blocking flag for 1802, as per schrep:

Josh has a patch for the TB binary - but it looks as if it has been some
time (many years) since we have rebuilt that binary.  Given the phase of the
schedule we are in, and the impact of this bug (i.e. hang when crash only
under Rosetta).  I recommend we release note it and tackle it next go
around.   I'd hate to add extra risk/work for build/qa at this phase.
Flags: blocking1.8.0.3?
Flags: blocking1.8.0.2-
Flags: blocking1.8.0.2+

Comment 14

11 years ago
Josh said his patch was to nsQfaServices.cpp, the Moz component and not the Talkback binary proper.  The component is rebuilt with each and every release build:

http://tinderbox.mozilla.org/showlog.cgi?log=Mozilla1.8.0/1143198420.16312.gz&fulltext=1

(search for nsQfaServices.cpp)
(Assignee)

Comment 15

11 years ago
Created attachment 216146 [details] [diff] [review]
Josh's patch to disable talkback under Rosetta

Josh's patch to stop Talkback from running under Rosetta; posting this for him, since he's on a plane today.
Attachment #216146 - Flags: review?(dbaron)
Attachment #216146 - Flags: review?(dbaron) → review+
(Assignee)

Comment 16

11 years ago
Doing a test build with this patch now.

Taking from Josh, since I'll be checking it in for 'im.
Assignee: joshmoz → preed
(Assignee)

Comment 17

11 years ago
Created attachment 216161 [details] [diff] [review]
Josh's patch + additional includes

Josh said these includes are needed as well; verified by the test build.
(Assignee)

Comment 18

11 years ago
Checked in (on the MOZILLA_1_8_0_BRANCH):

Checking in nsQfaServices.cpp;
/mofo/talkback/fullsoft/qfa/src/nsQfaServices.cpp,v  <--  nsQfaServices.cpp
new revision: 1.1.1.1.16.1; previous revision: 1.1.1.1
done

Leaving open, for Josh to resolve, in case he wanted to do anything else on this.

Comment 19

11 years ago
Was this also checked in on the 1_8 branch and trunk?
(Assignee)

Comment 20

11 years ago
(In reply to comment #19)
> Was this also checked in on the 1_8 branch and trunk?

No; I wanted to get a build with it for QA to test before porting it all over the tree.

It turns out that Dep builds don't rebuild the Talkback component (which isn't all that surprising... it changes what... once every couple of years?), so I had to do a full build, which is currently building:

http://tinderbox.mozilla.org/showlog.cgi?log=Mozilla1.8.0/1143247380.1574.gz&fulltext=1
Since I'm testing a 1.5.0.2 candidate build that includes this fix and I want some canned bugzilla queries to include this bug, I've changed the blocking flags and added the fixed1.8.0.2 keyword.

I've tested this fix on an intel mac running native and running under rosetta, and sending SIGSEGV to the firefox-bin process.  In both cases, firefox exited cleanly.


I'm about to test this build on ppc macs, to make sure talkback fires and logs crash data to the server.
Flags: blocking1.8.0.3?
Flags: blocking1.8.0.2-
Flags: blocking1.8.0.2+
Keywords: fixed1.8.0.2
talkback fires and sends crash data when firefox is sent SIGSEGV on ppc mac running 10.4.5 and 10.3.9

See <http://talkback-public.mozilla.org/search/start.jsp?search=1&searchby=stacksig&match=contains&searchfor=&vendor=MozillaOrg&product=Firefox15&platform=MacOSX&buildid=2006032416&sdate=&stime=&edate=&etime=&sortby=bbid> for talkback incidents.

We still need to test this on 10.2 for completeness, but I think the risk of breakage is low.
Has this been fixed for the 1.8 branch?  It has a blocking1.8.1? nomination, but no fixed1.8.1, so it's showing up on our queries.

Updated

11 years ago
Flags: blocking1.8.1? → blocking1.8.1+

Comment 24

11 years ago
-> josh
Assignee: preed → joshmoz

Comment 25

11 years ago
I wrote the patch for this, but I didn't check it in and I don't know how we deal with the repository the patch got checked in to (was it branched with the 1.8 branch? where do the 1.8 branch tinderboxes get their talkback glue code from?).

-> preed since he's more likely to know if/how this made it onto the 1.8 branch
Assignee: joshmoz → preed
(Assignee)

Comment 26

11 years ago
v2 of the patch (Josh's patch + additional includes) now checked in on the 1.8 branch and the trunk.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Keywords: fixed1.8.1
Resolution: --- → FIXED

Updated

8 years ago
Component: Talkback Client → Talkback Client
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.