Open Bug 1572680 Opened 5 years ago Updated 11 months ago

auto-scrolling leaves cursor behind overlay banner

Categories

(Firefox :: Disability Access, defect, P3)

Product:
Firefox
Component:
Disability Access
Version:
68 Branch
Type:
defect

Tracking

()

People

(Reporter: samuel.thibault, Unassigned)

References

Details

Attachments

(3 files)

google1.png
215.51 KB, image/png
Details
google2.png
215.10 KB, image/png
Details
test case: sticky-header.html
4.76 KB, text/html
Details
Attached image google1.png —

We have an issue with firefox auto-scrolling, which shows up in various situations. What I describe below is the easiest way to reproduce it, but there are more problematic usage situations further down, and notably for accessibility with a screen reader.

This happens both on Linux and Windows

Steps to reproduce:

  • Open google, make a search request. Make sure that the firefox window is not tall enough, so that not all results fit in the firefox window,
  • In the result list, tab between the result links down to the end, so that firefox has to scroll to show the last results,
  • shift-tab back between the result links up to the top, so that firefox will have to scroll to show the first results.
  • at some point one reaches the first visible link (and there are more links before that, but they are not visible yet)
  • at that point we can press shift-tab again to get from the first visible link to the previous link which is invisible

What is happening:
firefox scrolls a bit, but the link which was invisible is still not visible, it is hidden by the google overlay banner.

What should be happening:
firefox should scroll enough for the link to become visible, out of behind the google overlay banner.

I have attached a screenshot of the situation just before the last shift-tab press which is problematic: the focus is on the link showing up at the top of the screen. Pressing shift-tab at that point will switch focus to the previous link, but that link is hidden by the google overlay banner, and firefox doesn't scroll the link off that banner.

The reproduction scenario was just one example. It of course also happens with cursor navigation. What is way more problematic is that it also happens when a screen reader requests firefox to bring some object to be visible at the top of the window: firefox does scroll to make the object at the top of the window, but since the top of the window is partly hidden by the overlay banner, the object is always hidden by the banner, and the scrolling requested by the screen reader is always useless.

For a screen reader, being able to show an object at a location well-known to the user is an important thing for users with limited sight, so they do not have to look around to determine where the screen reader has scrolled what is being spoken. Putting it at the top left of the screen seems the best option, but with such a bug it becomes unusable.

Attached image google2.png —

This is what we get when we press shift-tab while the situation is as shown on google1.png.

Samuel, is this new behaviour, or something that has been with Firefox for a longer time already?

Flags: needinfo?(samuel.thibault)

And on websites with a banner at the bottom of the screen, this will pose problem simply when reading the page: the screen reader will request firefox to scroll to make the next that his off the window to become visible, but that will be hidden by the banner at the bottom of the screen.

This is not a new behavior, I have always seen it (seen on firefox 52 for instance).

But it is new that websites put banners at top/bottom of the screen, so this has become a serious concern for accessibility.

Flags: needinfo?(samuel.thibault)
See Also: → 1400420

What do other browsers do?

Flags: needinfo?(samuel.thibault)

Chromium and Konqueror have the same bug, I don't has a setup to test IE and Safari.

Flags: needinfo?(samuel.thibault)

Perhaps James can test IE?

Flags: needinfo?(jteh)

Unfortunately, I can't. I'm totally blind, so I can't see (or determine with a reasonable degree of certainty) whether the link is visible in this situation.

Flags: needinfo?(jteh)

The priority flag is not set for this bug.
:asa, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(asa)

Emilio, are there reasonable ways in which find-in-page and tab-focus based scrolling can detect that the node they're trying to scroll into view is being obscured by something not part of the scrolling container and that scrolling further would allow that node to become visible?

Flags: needinfo?(emilio)

Doesn't seem easy as a general problem. We could try to detect some of the common cases or doing something like the find-in-page code does (which afaics it works here because it tries to center the search range and it avoids this problem).

I think we provide means to authors to fix this via scroll-margin and scroll-padding, we should double-check they affect these. Hiro, do you know off the top of your head whether find-in-page / tab navigation? Otherwise I can double-check.

Flags: needinfo?(emilio) → needinfo?(hikezoe.birchill)

Yeah, scroll-padding is the one for such purpose, I believe.

Flags: needinfo?(hikezoe.birchill)

Looks like we could make the tab-focus code fix this by passing kScrollToCenter instead of kScrollMinimum - we will only scroll if the node isn't fully visible. I don't know if there's a compelling reason not to do that. Neil?

I don't know if the a11y code involved here is different from the focus manager code or if it passes through the focus manager.

Flags: needinfo?(enndeakin)

kScrollToCenter would not be ok for the accessibility requirements (the screen reader will most of the time request to go to the top or the bottom of the screen).

AIUI the a11y code passes through the focus manager.

(In reply to Samuel Thibault from comment #14)

kScrollToCenter would not be ok for the accessibility requirements (the screen reader will most of the time request to go to the top or the bottom of the screen).

I don't follow the objection. ScrollToCenter will mean that, if focus lands on an element that is not visible, it gets scrolled into the center of the viewport (inasmuch as that's possible). Why is that a problem for assistive technology? And if it is, doesn't that mean the current find in page behaviour is also problematic?

Flags: needinfo?(samuel.thibault)

kScrollToCenter will fix the auto-scrolling on caret movement yes (though UX people might say it's not the best behavior to exhibit), but that was only an easy way to show the issue.

The underlying issue I'm aiming at is that if the screen reader requests a piece of text to be scrolled at the top of the screen, it will be hidden by the overlay, thus making the feature useless.

Fixing the latter would also fix the former (without using kScrollToCenter instead of kScrollMinimum).

Flags: needinfo?(samuel.thibault)

(In reply to Samuel Thibault from comment #16)

The underlying issue I'm aiming at is that if the screen reader requests a piece of text to be scrolled at the top of the screen, it will be hidden by the overlay

The problem is that there's no straightforward way for Firefox to know that this is happening, and what the required scroll distance is to avoid the fixed overlay. Note also that in the google case, the overlay changes depending on the scroll offset on the page, too...

scroll-padding is apparently designed for authors to fix that problem, though I can't seem to work out how to use it successfully on the google page to avoid this problem, and either way it'd require work by each individual webpage that has this problematic pattern.

It seems simpler to fix this by centering the text, and I still don't really understand what your objection is against that behaviour...

I still don't really understand what your objection is against that behaviour...

I'm no UX expert so I'm only guessing, but AIUI such disruptive scrolling is not the easiest to immediately grasp for users.

Concerning a11y, a screen reader would have to be made to request scrolling to the center instead of the top, but that doesn't even exist yet in IAccessible2/at-spi.

Well, there are two different use cases here. One is tabbing via the keyboard, which would definitely benefit from Gijs's suggestion. The other is the request a screen reader sends to the scrolling of an element. That, IIUC, is not changed by Gijs's proposal. That has its own set of scrolling requests and would still behave like beore. So when a screen reader navigates with their document reading, and the screen reader requests that an element be focused/scrolled into view, that would not be the same as tabbing via the tab key, and thus be unaffected by this change.

the screen reader requests that an element be focused/scrolled into view, that would not be the same as tabbing via the tab key, and thus be unaffected by this change.

Sure, but then my original concern is still there: such screen reader requests become useless since the desired element actually becomes hidden.

Well, as Gijs said, there is no way for Firefox to know that a banner obscures the focused element. These banners are often generated in different ways, sometimes through intrusive CSS background images, or other obscure techniques, and there is no standard way for Firefox to know that. This scrolling to the center would at least make sure the elements are scrolled further than now, and thus the chances being higher that the banner does not obscure all of the element.

Jamie, do you have contacts to get new values into IA2ScrollType to add support for scrolling to center?

Flags: needinfo?(jteh)

NVDA at least currently uses IA2_SCROLL_TYPE_ANYWHERE, which is defined as:

  /** Scroll the object or substring such that as much as possible of the
   object or substring is within the top level window.  The placement of
   the object is dependent on the application.  For example, the object or
   substring may be scrolled to to closest edge, the furthest edge, or midway
   between those two edges.
  */

Technically, that means we could change this to centre and still be spec compliant. It would impact users, though. The question is whether this would be a good thing overall or a bad thing overall.

Note that NVDA is considering moving to IA2_SCROLL_TYPE_TOP_EDGE/IA2_SCROLL_TYPE_BOTTOM_EDGE due to the current scrolling experience being somewhat unfriendly/inconsistent across browsers. See issue, PR.

(In reply to :Gijs (he/him) from comment #15)

I don't follow the objection. ScrollToCenter will mean that, if focus lands on an element that is not visible, it gets scrolled into the center of the viewport (inasmuch as that's possible). Why is that a problem for assistive technology? And if it is, doesn't that mean the current find in page behaviour is also problematic?

I think what Samuel is getting at is that a screen reader user doesn't just use this for finding text (random access). They're also using this when reading linearly; e.g. moving line by line. If we always scroll to centre, that could result in some pretty jerky scrolling. Say the user is looking at something at the bottom of the screen and they press down arrow, which scrolls to something just below it which isn't yet visible. Instead of scrolling the minimum distance, we'll scroll this new thing to the centre, which will require the user to completely shift where they're looking.

Flags: needinfo?(jteh)

I don't follow the objection. ScrollToCenter will mean that, if focus lands on an element that is not visible, it gets scrolled into the center of the viewport (inasmuch as that's possible). Why is that a problem for assistive technology? And if it is, doesn't that mean the current find in page behaviour is also problematic?

The find in page only centers if the next item is outside the viewport. It would probably be ok to do that specifically with tab navigation as well (or with a screen reader), but that doesn't seem to help us here, does it? The point of this bug is that we don't know whether something is outside the logical viewing area due to these banners. It would be too jarring I think to always centre on focus change.

Flags: needinfo?(enndeakin)

I have submitted adding the center versions to IAccessible2 in https://github.com/LinuxA11y/IAccessible2/pull/12 , open for discussion.

I don't think the correct solution is to make ATs deal with this:

  1. The Shift+Tab example impacts all users; not just screen reader users. So making screen readers be the ones to deal with this strikes me as a bandaid; not a cure.
  2. What if there's a float in the middle? If that's the case, the AT-based work around won't even work for those users.

Either the user agents need to fix this or the sites need to fix it. The focused element needs to be visible -- regardless of whether or not there's an overlay and regardless of where that overlay may be. And it needs to be visible for all users -- not just screen reader users.

If the user agents all concur that this is not their bug -- or not a bug they can fix -- then we need to ensure there's standards which cover this problem and validators that test for it. It's not 100% clear to me if WCAG already covers this. https://www.w3.org/TR/WCAG21/#focus-visible looks promising.

(In reply to Joanmarie Diggs from comment #26)

  1. The Shift+Tab example impacts all users; not just screen reader users. So making screen readers be the ones to deal with this strikes me as a bandaid; not a cure.

I think the proposal here was to both a) patch the tab focus code (see comment 13) and b) change how screen readers request scrolling. Doing a) wouldn't be enough to fix the problem for screen readers because screen readers make scroll calls themselves.

  1. What if there's a float in the middle? If that's the case, the AT-based work around won't even work for those users.

Yeah; I was wondering about that too. This bug deals with banners at top or bottom, but couldn't there also be something in the middle?

Either the user agents need to fix this or the sites need to fix it. The focused element needs to be visible -- regardless of whether or not there's an overlay and regardless of where that overlay may be. And it needs to be visible for all users -- not just screen reader users.

Note that screen readers (at least JAWS and NVDA; i can't speak for Orca) scroll for more than just focus. There can be a lot of stuff on the page which isn't focusable and partially sighted users still need to be able to track their screen reading position visually. That's why a focus only patch isn't sufficient here.

I'm setting this as confirmed because I think we all agree there's a problem here. However, I still don't think we have an actionable solution yet that satisfies all of the outstanding issues, so I'm putting this in backlog for now.

Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3

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

(In reply to Joanmarie Diggs from comment #26)

  1. The Shift+Tab example impacts all users; not just screen reader users. So making screen readers be the ones to deal with this strikes me as a bandaid; not a cure.

I think the proposal here was to both a) patch the tab focus code (see comment 13) and b) change how screen readers request scrolling. Doing a) wouldn't be enough to fix the problem for screen readers because screen readers make scroll calls themselves.

Agreed regarding fixing the problem for screen readers. BUT if the user agent can identify that an element will be obscured in the Tab/focus case, then I assume that user agent can also determine this condition when the screen reader makes a scroll call. In which case:

  • If the screen reader call is to scroll to the top, but doing so will cause the element to be obscured by a banner overlay, then the user agent should scroll the element to immediately below the banner. (The top-most , still-visible location.)
  • If the screen reader call is to scroll to the bottom, but doing so will cause the element to be obscured by a footer overlay, then the user agent should scroll the element to immediately above the footer. (The bottom-most, still-visible location.)
  • If the screen reader call is to scroll to the middle, but doing so will cause the element to be obscured by some centered float overlay, then the user agent should scroll the element to <insert to-be-determined location here>.
  1. What if there's a float in the middle? If that's the case, the AT-based work around won't even work for those users.

Yeah; I was wondering about that too. This bug deals with banners at top or bottom, but couldn't there also be something in the middle?

Why couldn't there be? So what do we do? As I understand Samuel's proposal it's:

  1. Create new API to at least two platform accessibility APIs
  2. Ask screen readers to implement this new API
  3. Ask user agents to implement this new API
  4. Make end users look to a location that might not be their preferred location

This work would be done just to work around banners and footers which might not even be present, and can still fail because of floats in the middle of the screen. I'm sorry, but it seems like the wrong way to go to me.

I get that detecting that an element is obscured by another element is not going to be a simple task, but I think the user agents -- which are rendering the elements in the first place -- are in the best position to detect and deal with this situation. If that is not the case, then what do we need to make it possible for user agents to perform this detection?

This work would be done just to work around banners and footers which might not even be present, and can still fail because of floats in the middle of the screen. I'm sorry, but it seems like the wrong way to go to me.

In the navigation situation I'm aware of if there is a banner in the middle we can't do anything because:

  • The banner is on front of the page
  • The banner usually prevents the rest of the page to be visible with blurry mechanism

For situation between screen reader / screen magnifier or blind / sighted there is often someone able to close the middle banner because there is someone that can see.

The problematic use-case I see is the mouse click if there is a banner over the clickable link.

Best regards.

Flags: needinfo?(asa)

(In reply to Joanmarie Diggs from comment #28)

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

(In reply to Joanmarie Diggs from comment #26)

  1. The Shift+Tab example impacts all users; not just screen reader users. So making screen readers be the ones to deal with this strikes me as a bandaid; not a cure.

I think the proposal here was to both a) patch the tab focus code (see comment 13) and b) change how screen readers request scrolling. Doing a) wouldn't be enough to fix the problem for screen readers because screen readers make scroll calls themselves.

Agreed regarding fixing the problem for screen readers. BUT if the user agent can identify that an element will be obscured in the Tab/focus case, then I assume that user agent can also determine this condition when the screen reader makes a scroll call.

From what I understand, this is very much not trivial (see comment #11 / comment #12 from people who know about layout). We're just using the scroll-to-middle strategy for e.g. findbar (which already does this) to both (a) avoid fixed headers causing problems in "most" cases and (b) reduce the number of times we scroll when iterating through the document (which ultimately helps with both user attention and GPU/battery use etc.). It's an imperfect fix, but it's better than the alternative, esp. in the absence of a "perfect" solution.

As also noted in comment #11 / comment #12, there are ways web authors can fix this problem. Perhaps a tutorial on how to do so on MDN would be a helpful initiative? Emilio, do you know who could look into something like that, and/or if something is already available on the web? I recall that when I previously responded in this bug, I played around with this a bit but couldn't get it to work...

Floating content that obscures other content in the middle of a frame is much less common (no data, only anecdotes, I'm afraid, but still), so to my knowledge no effort has been made to solve that problem.

I think we should push ahead with a change to how tab focus works here because, like the find bar case, I think on balance it provides a better trade-off for usability than the status quo. Neil, I assume per comment #24 that you agree that makes sense (to do so if the item is outside the viewport, not always. Which indeed doesn't fix all the cases, but makes this slightly less painful, at least...) ? If we want to do that, we may want to do it in a separate bug (ie split it off from this one) so discussion re: AT/screenreaders can continue here.

I don't know what the right solution is for AT / screen readers - Jamie is probably in a better position to comment there.

Flags: needinfo?(enndeakin)

(In reply to :Gijs (he/him) from comment #30)

As also noted in comment #11 / comment #12, there are ways web authors can fix this problem. Perhaps a tutorial on how to do so on MDN would be a helpful initiative? Emilio, do you know who could look into something like that, and/or if something is already available on the web? I recall that when I previously responded in this bug, I played around with this a bit but couldn't get it to work...

Woops, forgot NI for this.

Flags: needinfo?(emilio)

I don't know if there are existing docs / blog posts on that no.

An easy test-case is https://bug1592001.bmoattachments.org/attachment.cgi?id=9104711. If you set something like scroll-padding: 10px on #scroller, then both child.scrollIntoView() and navigating to #child honor that padding.

Flags: needinfo?(emilio)

(In reply to :Gijs (he/him) from comment #30)

[...]

I think we should push ahead with a change to how tab focus works here because, like the find bar case, I think on balance it provides a better trade-off for usability than the status quo. Neil, I assume per comment #24 that you agree that makes sense (to do so if the item is outside the viewport, not always. Which indeed doesn't fix all the cases, but makes this slightly less painful, at least...) ? If we want to do that, we may want to do it in a separate bug (ie split it off from this one) so discussion re: AT/screenreaders can continue here.

Point of clarification: Are you saying that within the user agent, you can (or will be able to) detect when Tab focus causes something to be under a banner/footer and that should this happen, you'll adjust where the newly-focused item is scrolled to?

If so, then regarding this:

I don't know what the right solution is for AT / screen readers - Jamie is probably in a better position to comment there.

Would it be possible to detect when an AT scroll request would cause something to be under a banner/footer? If so, could you just disobey the AT? :)

The reason I ask is that there are a lot of pages out there which do NOT suffer from this problem. So I don't think we want to change the behavior of the user agent and/or AT to globally scroll to the middle just because there are SOME pages which do suffer from this problem. That might make the majority of pages less usable for some people.

If you could detect the AT-triggered problem similarly to the way you detect the Tab-focus-triggered problem, and adjust accordingly (hypothetically scroll to the middle instead), that strikes me as reasonable. Is this doable?

(In reply to Joanmarie Diggs from comment #33)

(In reply to :Gijs (he/him) from comment #30)

[...]

I think we should push ahead with a change to how tab focus works here because, like the find bar case, I think on balance it provides a better trade-off for usability than the status quo. Neil, I assume per comment #24 that you agree that makes sense (to do so if the item is outside the viewport, not always. Which indeed doesn't fix all the cases, but makes this slightly less painful, at least...) ? If we want to do that, we may want to do it in a separate bug (ie split it off from this one) so discussion re: AT/screenreaders can continue here.

Point of clarification: Are you saying that within the user agent, you can (or will be able to) detect when Tab focus causes something to be under a banner/footer and that should this happen, you'll adjust where the newly-focused item is scrolled to?

No. I'm saying that, if you tab/shift-tab, and the element is out of the scrollable viewport, right now we'll scroll "just enough" to have the newly-focused element inside the viewport. This breaks if some fixed thing (header/footer/whatever) is occluding the top/bottom of the viewport, which is what this bug is about. Instead of scrolling "just enough", we'll scroll the newly-focused element into the middle of the viewport. This is much less likely to be occluded by headers/footers or other content outside the viewport. We would always do this, it doesn't depend on detecting occluding content (which would be tricky at best). It's a workaround, but it'll help for tab/shift-tab use in the 90-99% case.

So I just landed a change in Orca master which uses accessibility API (AtkComponent) to look for a banner overlay and, if found, re-scroll the object so that it's just below the banner overlay. It works with Firefox and Google search results using Orca's structural navigation.

The thing is.... If I can figure this out by asking Firefox for information via AtkComponent, why can't this work be implemented directly into Firefox? That would be way more performant for end users -- and it would not require all screen readers to have to do this.

(In reply to Joanmarie Diggs from comment #35)

So I just landed a change in Orca master which uses accessibility API (AtkComponent) to look for a banner overlay

Look for it how?

Flags: needinfo?(jdiggs)

I think we should push ahead with a change to how tab focus works here because, like the find bar case, I think on balance it provides a better trade-off for usability than the status quo. Neil, I assume per comment #24 that you agree that makes sense

I think that seems reasonable.

Flags: needinfo?(enndeakin)

(In reply to :Gijs (he/him) from comment #36)

(In reply to Joanmarie Diggs from comment #35)

So I just landed a change in Orca master which uses accessibility API (AtkComponent) to look for a banner overlay

Look for it how?

https://gitlab.gnome.org/GNOME/orca/blob/e2cb51b/src/orca/eventsynthesizer.py#L333

Alex says this doesn't work for him (reason why TBD). But for me it's working quite well.

Your implementation of atk_component_get_accessible_at_point() is apparently diving down finding the deepest tree node at the specified coordinates. So I'm using that to look for an accessible object which is at the same y coordinate as the object to be shown but occupies the width of the document. I'm sure there will be edge cases, but at least it's a start....

Flags: needinfo?(jdiggs)

(In reply to Joanmarie Diggs from comment #38)

(In reply to :Gijs (he/him) from comment #36)

(In reply to Joanmarie Diggs from comment #35)

So I just landed a change in Orca master which uses accessibility API (AtkComponent) to look for a banner overlay

Look for it how?

https://gitlab.gnome.org/GNOME/orca/blob/e2cb51b/src/orca/eventsynthesizer.py#L333

Alex says this doesn't work for him (reason why TBD). But for me it's working quite well.

Your implementation of atk_component_get_accessible_at_point() is apparently diving down finding the deepest tree node at the specified coordinates. So I'm using that to look for an accessible object which is at the same y coordinate as the object to be shown but occupies the width of the document. I'm sure there will be edge cases, but at least it's a start....

OK. I'm having trouble parsing:

if not (left and right and left == right != document):

But there's a few assumptions/decisions here that I think we'd be reluctant to make in Firefox proper and/or use whenever we're scrolling as a result of user focus / findbar / AT scrolling:

  1. it only cares about the scrollable container being the document, not other scrollable things
  2. it probably (unsure how atk_component_get_accessible_at_point is implemented) gets the element with the highest z-index and assumes that that obscures things, irrespective of whether it is/isn't transparent, whether it takes/ignores mouse events, whether it's in the process of animating away (or animating further in), ...
  3. it only measures that innermost object that it happens to stumble upon, so it's not clear why it would get the right dimensions to use to adjust the scroll position - perhaps it's the containing object that is obscuring things, or the parent of that element, or ...
  4. it scrolls twice, which is likely to appear jumpy on slower machines / if page style changes in response to the scrolling
  5. it hardcodes 25 (something - px?) on top of the height of the banner - unclear what that's about...
  6. it only affects scrolling upwards
  7. it won't work if the scroll operation that adjusts for the position of the banner itself ends up changing layout (ie if the page CSS/JS responds to the scroll - which happens for me, the banner size on google.com search results is dependent on the vertical scroll position)

I think you misunderstood my suggestion. I'm not saying what I did is what you should do. I'm saying the following:

I came up with a very sad hack to work around this problem. It's a proof of concept.

The reason this very sad hack seems to work is your good implementation of atk_component_ref_accessible_at_point. That suggests to me that your implementation of atk_component_ref_accessible_at_point has access to some logic which makes it possible for you to identify within Gecko that some banner might be obscuring the element to be scrolled. In which case:

Could you please try to apply that logic you already have in Gecko to the problem at hand within Gecko, only scroll once, positioning the object immediately below the banner (with some margin, say 25 pixels, or whatever)?

(In reply to Joanmarie Diggs from comment #40)

Could you please try to apply that logic you already have in Gecko to the problem at hand within Gecko, only scroll once, positioning the object immediately below the banner (with some margin, say 25 pixels, or whatever)?

I don't know that that is possible. In order to scroll only once, gecko has to predict what will be at a certain point in the doc after a particular scroll, which is a lot harder than "what's going on right now", after scrolling once. I'm also not aware of a solution to (3), ie, if we find some element X', which is the correct ancestor element X' to use as the node which we decide will "obscure" things, and whose size we then use to adjust scrolling? Like, if we find the <a> in <div id=banner><p>Blah <a>some link</a> blah</p></div>, we should adjust scroll based on the banner div. How does gecko know? Ditto for (7).

Turns out there is a related bug related to Firefox's native caret navigation. Thus it's not Tab-related, nor is it something which can be solved by scrolling to the middle.

Steps to reproduce:

  1. Load the attached test case in Firefox.
  2. Be sure native caret navigation is enabled (F7)
  3. Press Ctrl+End
  4. Press Ctrl+Home

Expected results: The heading "Heading #1" would be visible on screen.

Actual results: The heading "Heading #1" is underneath the sticky banner.

Note: When native caret navigation is disabled, things work as expected.

Ok. I'll see if I can polish up my sad Orca hack, fix some bugs in it, and make it as smooth as possible and go from there. Thanks for listening. :)

(deleted)

Jamie pointed out this bug's relation to https://bugzilla.mozilla.org/show_bug.cgi?id=1642922.

That's a similar effect indeed. I guess it may not be completely the same cases, since while chromium doesn't seem affected by bug 1642922, it is affected by Joanmarie's testcase https://bugzilla.mozilla.org/attachment.cgi?id=9105335

Severity: normal → S3
See Also: → 1843227
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: