Closed Bug 1606721 Opened 4 years ago Closed 4 years ago

Crash in [@ mozilla::a11y::DOMtoATK::ATKStringConverterHelper::ConvertAdjusted]

Categories

(Core :: Disability Access APIs, defect, P2)

Product:
Core
Component:
Disability Access APIs
Platform:
Unspecified
Linux
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla80
Tracking Flags:
Tracking Status
firefox-esr68 --- wontfix
firefox-esr78 79+ fixed
firefox78 --- wontfix
firefox79 --- fixed
firefox80 --- fixed

People

(Reporter: mccr8, Assigned: samuel.thibault)

References

(Regression)

Details

(Keywords: crash, regression)

Crash Data

Attachments

(2 files)

Bug 1606721 - Fix crash on screen reader text requests with end offset smaller than -1, r=Jamie
47 bytes, text/x-phabricator-request
RyanVM
: approval-mozilla-beta+
RyanVM
: approval-mozilla-esr78+
Details | Review
Bug 1606721 - Fix crash on screen reader text requests with bogus offsets, r=Jamie
47 bytes, text/x-phabricator-request
RyanVM
: approval-mozilla-beta+
RyanVM
: approval-mozilla-esr78+
Details | Review

This bug is for crash report bp-a3606569-29d2-4618-8000-103960200101.

Top 10 frames of crashing thread:

0 libxul.so mozilla::a11y::DOMtoATK::ATKStringConverterHelper::ConvertAdjusted accessible/atk/DOMtoATK.cpp:134
1 libxul.so char* mozilla::a11y::DOMtoATK::NewATKString<mozilla::a11y::ProxyAccessible> accessible/atk/DOMtoATK.h:127
2 libxul.so getTextCB accessible/atk/nsMaiInterfaceText.cpp:147
3 libxul.so getTextAtOffsetCB accessible/atk/nsMaiInterfaceText.cpp:214
4 libatk-1.0.so.0.23312.1 libatk-1.0.so.0.23312.1@0x16380 
5 libatk-bridge-2.0.so.0.0.0 libatk-bridge-2.0.so.0.0.0@0x2048d 
6 libatk-bridge-2.0.so.0.0.0 libatk-bridge-2.0.so.0.0.0@0x202af 
7 libatk-bridge-2.0.so.0.0.0 libatk-bridge-2.0.so.0.0.0@0x21a80 
8 libatk-bridge-2.0.so.0.0.0 libatk-bridge-2.0.so.0.0.0@0x2195f 
9 libatspi.so.0.0.1 libatspi.so.0.0.1@0x17c7f

This is a very low volume crash (I only see a couple of crashes), but it is on a release assert so maybe it is actionable:
MOZ_RELEASE_ASSERT(aNewLength <= base_string_type::mLength) (Truncate cannot make string longer)

It looks like there's a call to truncate in ATKStringConverterHelper::FinishUTF16toUTF8. Maybe aStr is empty?

I did a crash stats search for that release message, and sure enough this also shows up as ATKStringConverterHelper::FinishUTF16toUTF8. The volume is a little higher (though still quite low!), but I think that's expected given that it is on release branches.

bp-e546573b-2f29-43a0-ab63-daea10200101

Crash Signature: [@ mozilla::a11y::DOMtoATK::ATKStringConverterHelper::ConvertAdjusted] → [@ mozilla::a11y::DOMtoATK::ATKStringConverterHelper::FinishUTF16toUTF8 ] [@ mozilla::a11y::DOMtoATK::ATKStringConverterHelper::ConvertAdjusted]

Hi, this is my crash:

https://crash-stats.mozilla.org/report/index/90f509f0-7bc2-47e6-ba2d-a5cee0200109

I have a lot of crashes, but using Debian's build. The crash above is using Mozilla's build and looks very similar, though:

bp-87786f25-149e-4f53-9106-7c9530191217
bp-e8b9919f-6d5f-4a49-8921-d38dc0191217
bp-41cf9866-008e-41d2-a2d1-21a130191217
bp-e54bb14e-b4b2-4675-a0be-b520c0191217
bp-a955cf71-f1bc-486d-9046-1a8540191217
bp-1455914d-3dc7-41ff-8fef-78ce40191217
bp-69bd4fae-a8d9-49b4-abb0-3bee00191217
bp-1e6d00a6-0f96-41dd-bc03-795800191217
bp-16ac9dcd-ff8e-4ca1-87ab-296460191216
bp-145d070d-cc2c-411a-ab60-e49a70191214
bp-83c075fa-d8c8-4adc-b3ee-149ec0191213
bp-ac598c8b-2700-4b48-ab60-2aca90191212
bp-8debc5ef-5884-4627-a46c-ee3e90191211
bp-ab92df80-a231-42fa-9fbf-d93350191211
bp-b3e0583d-b49e-4d7c-be64-6a5f40191210
bp-53c21b17-720f-4560-851e-0ef790191209
bp-372fc7cd-4819-4e5f-9ea2-5aed30191206
bp-ad110636-0731-4e4e-826f-6f5ee0191206
bp-ff326f43-c5c3-4d9f-a1de-3266c0191206
bp-a71d32af-46ab-463d-8c99-e0a740191206
bp-3fdd7f44-93fd-4584-a5c9-5b7c40191205
bp-5ce67dd1-1903-41c2-a07e-c94b60191205
bp-439373a2-e7df-467d-91d4-95f2c0191205
bp-273aa7e9-706f-4500-b547-3867a0191205
bp-2b6a3d6d-1b92-4e9a-b5c8-958810191204
bp-dede329b-d585-4096-ac2d-d5de10191204
bp-be9610f4-f648-4e01-84ec-b18610191204
bp-5fab6126-9a89-4114-b99d-0efef0191204
bp-3820b360-1eeb-452d-9139-3a32a0191203
bp-e599128c-1375-4a32-8c68-694af0191203
bp-3bea61dd-fdcf-4056-a591-4334a0191203
bp-bbc3d3bd-6f24-4630-a7a0-50eb90191203
bp-9aab135d-6172-47c3-9a53-f951a0191203
bp-936eef67-10f5-438d-ac59-fa34d0191202
bp-fbef01a3-d2dd-42bb-b04a-510f80191201
bp-bcef066a-7a20-4cd6-997e-ef5560191201
bp-39c9cab5-1714-46e5-a464-3f1ca0191129
bp-ec65d533-c5cb-45e1-afaf-860cd0191126
bp-38bab28f-1395-43d9-90bf-a04120191125
bp-e0d3345e-0011-4ab2-9f12-8a2240191125
bp-9a78c0e5-272e-40e7-9974-5008a0191125
bp-9cccd4ba-c41d-4088-922e-2dfd50191125
bp-21f96e47-c5d0-494d-b33f-fbba60191125
bp-005924ae-1c60-48ce-9999-d9e650191125
bp-225a7407-6e4c-4363-8b8e-a93800191122
bp-b25cc593-cc35-4b55-9612-c901b0191121
bp-3bf5c225-8446-41fc-be0f-757d80191120
bp-ca03c1c3-444f-4aa7-9c5a-c1f910191120
bp-39daa5f0-aad3-4bf9-8bc0-423150191120
bp-99e32027-574c-4a83-8299-1408e0191119
bp-02ad652e-da08-4e0d-a886-936b00191119
bp-8bfdeb10-08d5-4f69-9f74-46e920191118
bp-3bc640b6-24f8-45d4-8bdf-5e4df0191117
bp-030da293-9edc-478b-8a6b-37eb60191117
bp-caee034f-0323-4ee1-bc2d-024db0191115
bp-b1fc5bbd-166f-41d6-b33b-4f97d0191114
bp-660ee9d3-4dc5-4449-96e9-c3e7a0191114
bp-f4f966b2-a417-445e-b018-3b0910191114
bp-19b55bff-3104-4c90-8324-a25230191113
bp-f772f69f-3d94-466d-96fc-8e1690191113
bp-f819a7d4-ff18-4953-9d21-7c98e0191112
bp-0a5c7323-0d03-4e66-9dce-e74930191112
bp-32003059-f693-406d-869c-db9790191112
bp-bc5495e5-2baa-4c9b-b759-d07520191111
bp-51b0074e-63a1-4fea-9c8c-8d4ee0191111
bp-f86d34c1-bb9a-4c99-a254-4baad0191111
bp-89dd9b00-e971-4048-8590-ab3f30191111
bp-038cfd39-4c60-4cc2-962a-96dc90191111
bp-2b7da6ce-76ae-49a6-b7c7-0aae40191111
bp-7a56a01a-eb08-4ee5-9233-2b9980191111
bp-50f490ca-ffc4-4d10-8e51-7a1040191109
bp-f85685e5-9972-470f-93d1-ccb710191108
bp-a92432f2-7632-4d39-b2ea-fa9a30191108
bp-7dd563f9-9933-41d9-b274-c1f3d0191108
bp-afc4cecd-756a-4400-81f2-a57990191107
bp-1c3faccb-6aa2-446c-879e-c9a570191107
bp-cef48d82-dc33-4fcf-916f-cb8540191107
bp-3b645d8c-8515-4b3c-be64-1bc3a0191107
bp-a1926c98-3186-481d-bae0-6ccdc0191107
bp-567d1f64-f6d6-4e1f-8b2d-3a0d60191107
bp-84973eb8-050c-4851-a926-7e2110191107
bp-a78d2d62-1532-47b8-b0cd-096e50191107
bp-89a76344-163f-4aed-a7eb-61c370191107
bp-2e307460-96f5-484a-a911-ecf620191107
bp-bb85295f-3bab-40d1-8d4e-eaac50191107
bp-683b968e-7118-4a49-b68d-625860191107
bp-651a3abd-2af8-4057-8f71-bb0570191107
bp-9dbeb0be-269a-4cc0-9f4a-c01550191107
bp-2f2c0dde-05a9-4b50-ba30-d60a80191107
bp-777ce9b8-16a1-4a6f-b895-72ce80191107
bp-de5471bc-eb39-42a4-8ff1-7940f0191107
bp-fa633e8b-16bf-4ed6-abf7-505610191106
bp-dbcda3fe-a070-4711-aba6-dc4e50191106
bp-e5fb49f6-9637-410b-9d30-f253b0191106
bp-055e8a0f-fd2c-4c1c-9b03-ee5920191106
bp-12870b02-35cc-49f2-92cf-ac9ea0191106
bp-bfe730ff-9b33-41c2-97c1-313a20191106
bp-c7411f81-01fb-42e4-a092-002f60191105
bp-cf4a3a7f-4345-4e7e-bd71-8c09c0191104

I started getting these crashes when I upgraded to ESR 68. I didn't get them before.

The most reliable way I have of reproducing these crashes is in Twitch chat. If I go into Twitch chat, type out a lot, and then hold down the the backspace key to delete everything, I see Firefox eating a lot of CPU. Usually it crashes. Keymashing in Twitch chat usually works too, which is how I've naturally ran into these crashes. I'm starting to get conditioned to not type too quickly in chat.

Component: Disability Access → Disability Access APIs
Priority: -- → P2
Product: Firefox → Core

I have a suspicion that this is an unintentional ABI compatibility in libatk in Debian. I noticed that libatk was at a different version in Debian backports compared to related libraries like libatspi2.0a that was at the stable version.

I have downgraded libatk to its stable version instead of backports and haven't been able to reproduce a crash since then.

I mean, an unintentional ABI break.

Maybe one of the Debian maintainers can help here.

Flags: needinfo?(sledru)
Flags: needinfo?(mh+mozilla)

If it's an ABI break in libatk, there's probably not much Debian can do short of updating the version in backports, assuming that one is fixed (since it's now also outdated compared to what's in testing/unstable).

It would helpful, though, to start by getting more useful crash traces by getting the symbols from the libatk packages in buster-backports.

Flags: needinfo?(sledru)
Flags: needinfo?(mh+mozilla)
Flags: needinfo?(gsvelto)

Maybe aStr is empty?

There is a MOZ_ASSERT(aStr.Length() > 0) assertion above. Are such assertions not compiled in in these cases?

It would be very useful to have a backtrace with the value of the parameters.

(I don't think the symbols from the libatk will help very much, they will most probably only show that it's a GetTextAtOffset request from the screen reader, which we already knew from the libxul trace)

I noticed that libatk was at a different version in Debian backports compared to related libraries like libatspi2.0a that was at the stable version.

I checked the difference between 2.30 and 2.34/36, I didn't find any ABI difference, let alone that get have exactly this kind of crash.

FWIW, I have now uploaded the 2.36 version of ATK to the backports.

I would rather think of a feature introduced in the 2.34 or 2.36 stack, that makes the screen reader benefit from it and change its behavior, and have bugs in there that triggers the crash here.

For instance, possibly Orca passes -2 (or some other negative value below -2) as end offset, and that has undefined behavior in the API. Firefox doesn't seem to take care of this case.

We were missing atk symbols (and related libraries) on all distros so I've added them to the scraping script. After retrieving the symbols I've reprocessed the last week worth of crashes but not many matched the new symbols, I think I know why but I need to investigate further.

This one did match the new symbols and now has a proper stack trace.

Flags: needinfo?(gsvelto)

Jordi, since you have a way to reproduce the issue, could you try this version

https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/GVD85O40TOSRlN1kyRYM8w/runs/0/artifacts/public/build/target.tar.bz2

(from the 'try' build https://treeherder.mozilla.org/#/jobs?repo=try&revision=aae490c8c171fb9090acbe9642c83322a35ebffe&selectedJob=297252022)

which includes a fix for the -2-and-below case?

Flags: needinfo?(jordigh)

I found another issue with the symbols and fixed it, now (almost) all the crashes should have detailed symbols in the stack trace + file names and line numbers in the original source.

Samuel, here is the crash with the build you suggested,

https://crash-stats.mozilla.org/report/index/8a517913-a16e-40fd-bf7a-e7ea30200423

I don't know why there seem to be no symbols for libxul, but it looks very similar to my usual crash on ESR:

https://crash-stats.mozilla.org/report/index/d427147b-0c1a-4937-9357-4d3860200417

Flags: needinfo?(jordigh)

And oops, I forgot to say, this is with libatk 2.30.0-2 from Debian stable. I seem to be getting slightly different crashes than with libatk 2.36.0-2~bpo10+1 from Debian backports.

I was able to reproduce this bug on 78.0esr using Jordi's method of holding down backspace in Twitch chat. I also have libatk 2.30.0-2 so my crash looks very similar:

https://crash-stats.mozilla.org/report/index/00604df1-9daf-4cb7-906d-43e090200705

I'm curious about Jordi's comment 3 months ago about how downgrading libatk "to its stable version" can prevent the crash. Which version exactly is the one that doesn't crash?

I still can not reproduce the issue with holding backspace in the Twitch chat. Just to be sure:

  • what text did you have in the textbox of the chat? did it contain only ascii? non-ascii but 16bit unicode? emojis?
  • are you running orca with speech synthesis or braille?

Is there really no way to get firefox' crash report to actually print the parameters of the function calls? The backtrace shows where the crash happens, but not why...

Brian, I am no longer sure. I am right now on the libatk1.0-0 Debian package at version 2.30.0-2

I still get crashes with atk in the stack trace, but I get different ones now:

https://crash-stats.mozilla.org/report/index/55255090-c457-48b0-9daf-597c60200705
https://crash-stats.mozilla.org/report/index/c8c3157d-1177-409b-86f7-317fb0200704
https://crash-stats.mozilla.org/report/index/d58fb261-9c6b-48f7-899d-e46e20200703

I always happens during user input. I click on a button or link, I experience a freeze for a few milliseconds, and then I get a crash.

Sam, I don't think I'm running Orca, but just in case, I just removed the package. And yes, there's only ASCII in Twitch chat, but I don't think that's relevant.

The crashes in comment 20 have the same raw crash reason as the previous ones: Truncate cannot make string longer so they're still happening here. What's interesting is that the first frame in the stack is garbled so this might be some kind of buffer overflow on the stack that messes up the frame.

And if I read the stack correctly the call that's involved is this one. The only way we can hit that assertion is if trail is negative, because it's an int and it gets passed to Truncate that takes size_t instead. Now the only way to get a negative trail is if we never break out of this loop, in which case trail will be -1 upon exit. Note that we have assertions that check against that happening, but they're enabled only in debug build while the assertion that causes the crash here is enabled in release builds too (which is why we're not tripping over those other assertions).

Samuel is this helpful? Do you need more info from the minidump? I have the right permissions to download the raw crash and I can inspect it in a debugger.

Jordi: not running Orca? I wonder how you end up seeing GetStringAtOffset called then. Do you have some other assistive technology running? Or perhaps compiz or mutter is running?

Assignee: nobody → samuel.thibault
Status: NEW → ASSIGNED
Attachment #9161540 - Attachment description: Bug 1606721 - Fix crash on screen reader text requests with current caret offset, r=Jamie → Bug 1606721 - Fix crash on screen reader text requests with end offset smaller than -1, r=Jamie

(In reply to Samuel Thibault from comment #24)

Jordi: not running Orca? I wonder how you end up seeing GetStringAtOffset called then. Do you have some other assistive technology running? Or perhaps compiz or mutter is running?

His crashes have the Accessibility crash annotation set and so do all the other crashes under the signatures here, so there must be something enabled.

Gabriele: well, I also had such reasoning, but that's not supposed to happen: mEndShifted means that in ATKStringConverterHelper::AdjustOffsets we asked for another character, which does exist since *aEndOffset < count, and thus there should actually be a character to be found by the trail loop.

One scenario that I can think of leading to the issue is *aEndOffset being less that 0 (and not only -1). I had proposed such a fix in comment 14, but Jordi said he still had the crash... I'm however thinking that even if it doesn't seem to be fixing the issue we should commit it, it does make sense and would fix other issues, I have submitted on https://phabricator.services.mozilla.com/D82324

What would be useful would be to reproduce the crash with a debug-enabled build, to have the various assertions catch odd cases, rather than only the last production assertions.

Samuel, do you want to wait for things you learn from that debug build to update the patch, or do you want to deal with possible follow-ups in a separate patch to the one you submitted?

Flags: needinfo?(samuel.thibault)

The patch as it is stands by itself, so I'd say we can deal with follow-ups in separate patches.

Flags: needinfo?(samuel.thibault)

I am running Compiz, yes.

Oh, interesting. I can't quickly repro without Compiz. And it's much faster to type in Twitch chat without Compiz.

Ok so that could be coming from the focuspoll plugin. I wonder why you are seeing calls from it, though, it's not supposed to look at the accessible interface if you are not actually zooming with the ezoom plugin, are you perhaps zooming sometimes?

Could you try the debug version from

https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/bjzWov__Tz6Jeaj5y3JFzw/runs/0/artifacts/public/build/target.tar.bz2

to see if a more precise assertion pops up?

I do zoom in sometimes, but not during a crash.

So after disabling that Compiz plugin, I can no longer repro the crash either.

I tried the nightly, but instead of crashing Firefox, all of X froze (well, except the mouse, that still moved). When killing Firefox from a tty, other running programs like my mate terminals also died along.

Alright, now I can reproduce the issue with compiz :)

Indeed, the debug version of firefox seems to be turning crashes into a hang, and with video accelerated rendering etc. that freezes X and more generally brings mayhem.

Anyhow, I could get the error messages, here is what comes:

###!!! ASSERTION: Wrong in offset: 'Error', file /builds/worker/checkouts/gecko/accessible/generic/HyperTextAccessible.cpp, line 163
Assertion Failure: aStr.Length() > 0 (There should be a leading character), at /builds/worker/checkouts/gecko/accessible/atk/DOMtoATK.cpp:87

So the problem seems to be that compiz' focuspoll plugin is requesting outdated text offsets (which is not surprising since all of this is asynchronous), but then the DOMtoATK conversion is surprised to be getting an empty string. I'll have a look at fixing those.

As envisioned above, this follow-up will be very independent from the first patch I attached to this bug.

I'm so happy that I at least have a workaround for now. It's been almost a year of frequent crashes for me. I have forgotten what life without crashing looks like.

I have started opt & debug builds on https://treeherder.mozilla.org/#/jobs?repo=try&revision=e770326919a29449c591fb40c9968af8868efdf5

Jordi: you do not need to disable ezoom plugin entirely, you can just disable the focuspoll plugin

(In reply to Samuel Thibault from comment #38)

Jordi: could you try the debug version:

https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/X4xnJOAET8-sVz8M8KLdxg/runs/0/artifacts/public/build/target.tar.bz2

or the production version:

https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/Ts9Ja5quQ5i9XvZedzNTfg/runs/0/artifacts/public/build/target.tar.bz2

I cannot reproduce the issue any more with the two patches in.

I confirm too, I can't reproduce it anymore.

Thanks for fixing it.

Flags: needinfo?(jordigh)

It seems realllllyyy slow but at least it doesn't crash.

Oh, that was the debug version. But I assume that's enough of a check.

Jamie, could you have a look at the two patches? They are both one-liners, and we will probably want to backport them as much as possible, the issue dates back firefox 60.

Flags: needinfo?(jteh)
Pushed by jteh@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/2dd595068ba7
Fix crash on screen reader text requests with end offset smaller than -1, r=Jamie
https://hg.mozilla.org/integration/autoland/rev/d80ff2f3f625
Fix crash on screen reader text requests with bogus offsets, r=Jamie
Severity: normal → S2
status-firefox78: --- → affected
status-firefox79: --- → affected
status-firefox80: --- → affected
status-firefox-esr68: --- → wontfix
status-firefox-esr78: --- → affected
Flags: needinfo?(jteh)
Keywords: regression
Regressed by: 1346535
Has Regression Range: --- → yes

esr68 wontfix? But that's the one I'm using. :-(

Is esr68 already out of support?

Is there any way to know when the fix gets released? (I'm on esr78, if that's relevant)

https://hg.mozilla.org/mozilla-central/rev/2dd595068ba7
https://hg.mozilla.org/mozilla-central/rev/d80ff2f3f625

Status: ASSIGNED → RESOLVED
Closed: 4 years ago
status-firefox80: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla80

Another wontfix?

Is there an explanation somewhere of just what is fixed for ESR? I couldn't find it on Mozilla's wiki.

(In reply to Jordi Gutiérrez Hermoso from comment #47)

Another wontfix?

Is there an explanation somewhere of just what is fixed for ESR? I couldn't find it on Mozilla's wiki.

Jamie, do you think the fix is enough safe to be backported to version 78? As it's a crash, I think it would be relevant to backport it.

Thanks in advance.

Flags: needinfo?(jteh)

For now, the WONTFIX only applies to the regular Firefox78. Firefox-ESR78 has a separate flag, and that is still set to "Affected", meaning a decision has not yet been made for the ESR version. This is being treated separately.

Flags: needinfo?(jteh)

So is ESR 68 already out of support? Or is this not potentially a security bug? It looked like the crash ended up being a stack smash, which I bet could be exploited with some dedication.

(In reply to Jordi Gutiérrez Hermoso from comment #50)

So is ESR 68 already out of support?

Not quite, but it's very close. ESR 68 is now only used by enterprises that cannot yet commit to updating to ESR 78. I'd say only serious security fixes would get into ESR 68 at this point.

Or is this not potentially a security bug? It looked like the crash ended up being a stack smash, which I bet could be exploited with some dedication.

The crash address in all the crashes I saw was 0x0, so I don't think this is an exploitable security problem.

Would someone affected be able to verify that this is fixed on Firefox Nightly? Once it's verified there, I can start the process of requesting uplifts to beta, 78 ESR, etc. Thanks.

I am not an enterprise that cannot commit to updating to ESR 78. I'm a Debian user.

It's okay, I'll either do my backport or hope that Debian moves a newer ESR into stable.

(In reply to James Teh [:Jamie] from comment #52)

Would someone affected be able to verify that this is fixed on Firefox Nightly? Once it's verified there, I can start the process of requesting uplifts to beta, 78 ESR, etc. Thanks.

I was affected by the crash and I'm running Nightly and I confirm:

  1. I don't reproduce the crash anymore (my last crash was before the patch landed)
  2. I don't see any regressions using both the Orca screen reader and the Compiz screen magnifier

Comment on attachment 9161540 [details]
Bug 1606721 - Fix crash on screen reader text requests with end offset smaller than -1, r=Jamie

Beta/Release Uplift Approval Request

  • User impact if declined: Crashes for users of Linux accessibility tools.
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Simple bounds checks.
  • String changes made/needed:
Attachment #9161540 - Flags: approval-mozilla-beta?
Attachment #9161700 - Flags: approval-mozilla-beta?

Comment on attachment 9161540 [details]
Bug 1606721 - Fix crash on screen reader text requests with end offset smaller than -1, r=Jamie

Approved for 79.0b8.

Attachment #9161540 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Attachment #9161700 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

[Tracking Requested - why for this release]: Frequent crashes for some users of Linux accessibility tools.

tracking-firefox-esr78: --- → ?

Alex ARNAUD, could you please verify that the bug is also fixed in Firefox 79 Beta 8 (https://archive.mozilla.org/pub/firefox/candidates/79.0b8-candidates/build1/)?

Flags: needinfo?(aarnaud)

Please nominate this for ESR78 approval if we want to include it in the next release. RC week is next week.

Flags: needinfo?(samuel.thibault)

Camelia: I can confirm that that firefox 79 beta 8 build doesn't have the issue any more.

Flags: needinfo?(aarnaud)

Comment on attachment 9161540 [details]
Bug 1606721 - Fix crash on screen reader text requests with end offset smaller than -1, r=Jamie

ESR Uplift Approval Request

  • If this is not a sec:{high,crit} bug, please state case for ESR consideration: The fixes are trivial one-liners on bound checking, which put us on a safer side than the existing code.
  • User impact if declined: The bug triggers daily crashes for users of Linux accessibility tools (which can be mere users of compiz with even infrequent magnification)
  • Fix Landed on Version: 79 beta8
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Simple bounds checks.
  • String or UUID changes made by this patch:
Flags: needinfo?(samuel.thibault)
Attachment #9161540 - Flags: approval-mozilla-esr78?
Attachment #9161700 - Flags: approval-mozilla-esr78?

(In reply to Samuel Thibault from comment #61)

Camelia: I can confirm that that firefox 79 beta 8 build doesn't have the issue any more.

Thank you!

Comment on attachment 9161540 [details]
Bug 1606721 - Fix crash on screen reader text requests with end offset smaller than -1, r=Jamie

Approved for 78.1esr.

Attachment #9161540 - Flags: approval-mozilla-esr78? → approval-mozilla-esr78+
Attachment #9161700 - Flags: approval-mozilla-esr78? → approval-mozilla-esr78+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: