1297131 - [e10s][a11y] Crash in IPCError-browser | (msgtype=0x5C000A,name=PDocAccessible::Msg_BindChildDoc) Processing error: message was deserialized,

Status: RESOLVED DUPLICATE of bug 1270916

(Core :: Disability Access APIs, defect)

Description

[Alice0775 White]

This bug was filed from the Socorro interface and is 
report bp-dbdeba6e-c697-45dc-b1e4-1476b2160822.
=============================================================

Reproducible : none

Steps to reproduce:
1. Search Facebook from SearchBar
2. Click a link in the results
   i.e., https://www.google.co.jp/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwi3p7ixwNXOAhVBtJQKHZkZClUQFggjMAA&url=https%3A%2F%2Fja-jp.facebook.com%2F&usg=AFQjCNF2AhfF-R00mWMvTx9TbBKZPxDMYQ
3. A Master Password Prompt pops up and enter master password and Clock[OK] 
4. Double click login id field in the top bar

Actual Results:
Crash

Comment 1

[Alice0775 White]

Reproduced the crash with the same STR.
bp-e4020113-4551-43ab-a768-8a04a2160822

Comment 2

[Alice0775 White]

bp-994bb721-e1f4-4849-8a68-ab7412160823
bp-04ba1781-a76d-4f04-ab04-dbab72160823
bp-630a6397-c34c-4446-9e86-c96112160823

Reproducible crashes when I click playback button on [1].

[1]
http://en.rocketnews24.com/2016/08/23/typhoon-turns-tokyo-motorists-drive-home-into-crazy-aquatic-voyage-in-flooded-tunnel-%e3%80%90video%e3%80%91/

Comment 3

[Alice0775 White]

[Tracking Requested - why for this release]:

Regression window(STR Comment 2)
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=85105a2f62d24ffe97e37ae70df08f6b23fe5e0f&tochange=b50c1f98bff8ae9efb5dc7ed3d0b53ac1bb8fa70

Suspect:
43d72f3a7ae1	Alexander Surkov — Bug 1274381 - scope accessible elements search to inserted nodes, r=yzen, f=marcoz

Comment 4

[alexander :surkov (:asurkov)]

We probably see here two different crashes, because bug 1274381, which was named guilty, was landed Aug 5 [1], but the crash path [2] was introduced later Aug 18 [3] by bug 1268544.

Can we have a crash stack before bug 1268544 was landed?

Aaron, could you please take a look at the crash stack too?

[1] https://hg.mozilla.org/integration/mozilla-inbound/rev/43d72f3a7ae1
[2] bp-e4020113-4551-43ab-a768-8a04a2160822
[3] https://hg.mozilla.org/mozilla-central/rev/ad2a728e5832

Comment 5

[Alice0775 White]

With 16-Aug-2016 Nightly build cset 054d4856cea6150a6638e5daf7913713281af97d
(this does not include bug 1268544)

bp-ac4d511e-54bb-46bb-816d-085fa2160823
bp-dc2ded4d-d7a5-40fb-89ca-3f7a12160823
bp-2696e710-6862-4d2d-ab9f-a06092160823

Comment 6

[alexander :surkov (:asurkov)]

(In reply to Alice0775 White from comment #5)
> With 16-Aug-2016 Nightly build cset 054d4856cea6150a6638e5daf7913713281af97d
> (this does not include bug 1268544)
> 
> bp-ac4d511e-54bb-46bb-816d-085fa2160823
> bp-dc2ded4d-d7a5-40fb-89ca-3f7a12160823
> bp-2696e710-6862-4d2d-ab9f-a06092160823

these are something 3d, as they don't have a11y on stack at all, I'm not sure why they share same crash signature.

Comment 7

[Alice0775 White]

Regression window(m-i x64)
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=85105a2f62d24ffe97e37ae70df08f6b23fe5e0f&tochange=43d72f3a7ae103cb195a6aff1e65defddf8209b9

Same suspicion Bug 1274381 ...

With 07-Aug-2016 Nightly x64 build cset d42aacfe34af25e2f5110e2ca3d24a210eabeb33
bp-796085cc-be50-470f-ac55-ae4102160823
bp-4b786282-4693-4f31-871c-72af02160823
bp-b95c1695-166e-41ca-bf6a-57e8f2160823

Comment 8

[alexander :surkov (:asurkov)]

(In reply to Alice0775 White from comment #7)

> Same suspicion Bug 1274381 ...
> 
> With 07-Aug-2016 Nightly x64 build cset
> d42aacfe34af25e2f5110e2ca3d24a210eabeb33
> bp-796085cc-be50-470f-ac55-ae4102160823
> bp-4b786282-4693-4f31-871c-72af02160823
> bp-b95c1695-166e-41ca-bf6a-57e8f2160823

there's definitely something weird with the stacks, these three are all different and contain no a11y calls. Does anyone have ideas? What tool did you use to find the suspicion? I wish to have a better idea on how it finds it based on such questionable stacks.

(In reply to Alice0775 White from comment #0)
> Steps to reproduce:
> 1. Search Facebook from SearchBar
> 2. Click a link in the results
>    i.e.,
> https://www.google.co.jp/
> url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwi3p7ixwNXO
> AhVBtJQKHZkZClUQFggjMAA&url=https%3A%2F%2Fja-jp.facebook.
> com%2F&usg=AFQjCNF2AhfF-R00mWMvTx9TbBKZPxDMYQ
> 3. A Master Password Prompt pops up and enter master password and Clock[OK] 

it doesn't popup up for me, what does make it to pop up?

Comment 9

[Alice0775 White]

You should set Master password from Option > Security.
I think STR comment#2 is easy to reproduce the crash.

By the way, 
The following preference seems to prevent the crash.
user_pref("accessibility.force_disabled", 1);

Comment 10

[alexander :surkov (:asurkov)]

(In reply to Alice0775 White from comment #9)
> You should set Master password from Option > Security.
> I think STR comment#2 is easy to reproduce the crash.

I see the crash, but no a11y on stack, it crashes inside PressShell::Paint while building display lists, similar to crashes from comment #5. It would be definitely good to show this to a layout peer.

> By the way, 
> The following preference seems to prevent the crash.
> user_pref("accessibility.force_disabled", 1);

it's interesting, a11y seems correlates with the crash quite implicitly.

Comment 11

[Trevor Saunders (:tbsaunde)]

(In reply to Alice0775 White from comment #7)
> Regression window(m-i x64)
> https://hg.mozilla.org/integration/mozilla-inbound/
> pushloghtml?fromchange=85105a2f62d24ffe97e37ae70df08f6b23fe5e0f&tochange=43d7
> 2f3a7ae103cb195a6aff1e65defddf8209b9
> 
> Same suspicion Bug 1274381 ...

nah, its basically just a specific case of bug 1185277, which is caused by the same issues as bug 1272706.  Note I'm not done debugging yet, but I'm pretty sure from what I've seen so far.  Of course that bug may have made it worse or something.

(In reply to alexander :surkov from comment #8)
> (In reply to Alice0775 White from comment #7)
> 
> > Same suspicion Bug 1274381 ...
> > 
> > With 07-Aug-2016 Nightly x64 build cset
> > d42aacfe34af25e2f5110e2ca3d24a210eabeb33
> > bp-796085cc-be50-470f-ac55-ae4102160823
> > bp-4b786282-4693-4f31-871c-72af02160823
> > bp-b95c1695-166e-41ca-bf6a-57e8f2160823
> 
> there's definitely something weird with the stacks, these three are all
> different and contain no a11y calls. Does anyone have ideas? What tool did
> you use to find the suspicion? I wish to have a better idea on how it finds
> it based on such questionable stacks.

the stacks are probably fine, they're just irrelevant.  The problem is the main process got sent a bad async message, so the content process got killed, but its off doing something unrelated, and so the stack is uninteresting.

Comment 12

[Marcia Knous [:marcia]]

Tracking 51+ for this crash, especially since it is a regression and reproducible.

Comment 13

[(No longer employed by Mozilla) Aaron Klotz]

For some reason socorro is displaying the wrong process in many of these dumps. It's showing content stacks when it's the chrome stack that has crashed.

Comment 14

[Justin Dolske [:Dolske]]

Starting with the latest Nightly (or so) on OS X, I'm getting almost 100% crashes with this signature when I load Facebook.

bp-370b2ff9-2e9f-4cdf-bb92-a54fa2160914
bp-aed8ff59-c933-475c-9bfa-08be12160914
bp-494d0bb3-669f-4127-89ff-0c47e2160914

Comment 15

[Kartikaya Gupta (email:[e-mail])]

On IRC Trevor said this is basically a dupe of bug 1270916, so duping over.

Comment 16

[Liz Henry (:lizzard) (relman/hg->git project)]

This is still affecting 51, but it won't be for 51 beta. So we aren't tracking for 51 in the duplicate bug - only for 52.

Comment 17

[Gerry Chang [:gchang]]

Mark 51 won't fix as the volume of crash is low.