Open Bug 372624 Opened 17 years ago Updated 2 years ago

Float or position: absolute interferes with keyboard navigation (Ctrl+Home/End) within page content

Categories

(Core :: DOM: UI Events & Focus Handling, defect, P4)

Product:
Core
Component:
DOM: UI Events & Focus Handling
Type:
defect

Tracking

()

People

(Reporter: jdiggs, Unassigned)

References

(Blocks 3 open bugs)

Details

(Keywords: access, Whiteboard: orca:urgent)

Attachments

(2 files)

aforementioned test case
715 bytes, text/html
Details
draft patch
2.67 KB, patch
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a3pre) Gecko/20070302 Minefield/3.0a3pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a3pre) Gecko/20070302 Minefield/3.0a3pre

The presence and location of <div style="position: absolute;"> and </div> impact whether or not Control Home/End work and where they, along with Up/Down Arrow, will allow you to navigate.

Reproducible: Always

Steps to Reproduce:
Using the test case (to be attached), attempt to use Control Home to move to the top of the content, Control End to move to the end of the content, and Up/Down Arrow to move by line within the content.  
Actual Results:  
1. When the div encloses everything contained between <body></body> (as it does in the test case), Control Home and Control End don't work; but you can use Up/Down Arrow to navigate among all of the lines.

2. Removing the 'style="position: absolute;"' from the div (leaving the div itself) causes the problem goes away.

3. Moving the <div style="position: absolute;"> and/or </div> so that it is surrounding only a portion of the body text causes Control Home/End and Up/Down Arrow to only move you within the content that is not enclosed.

Expected Results:  
Control Home/End and Up/Down Arrow would allow the user to navigate to all of the content in a page.

    
  
Keywords: access

    
  
Blocks: orca

    
  
Blocks: focusnav, caretnav

    
  
Component: Keyboard Navigation → Keyboard: Navigation
Product: Firefox → Core
QA Contact: keyboard.navigation → keyboard.navigation

    
    

    
  
Is this something Ginn can help us with?

    
    

    
  
Ginn can reassign if necessary.
Assignee: nobody → ginn.chen

    
  
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: position: absolute interferes with keyboard navigation within page content → position: absolute interferes with keyboard navigation (Ctrl+Home/End) within page content

    
    

    
  
Uri, can you take this?

    
    

    
  
The up/down arrow issue is bug 369855 (position:absolute and floats are essentially the same for this matter).

I'll try to have a look at the home/end issue, but I can't really promise anything as I don't have much Mozilla time these days. 

    
    

    
  
(In reply to comment #5)
> The up/down arrow issue is bug 369855 (position:absolute and floats are
> essentially the same for this matter).
> 
> I'll try to have a look at the home/end issue, but I can't really promise
> anything as I don't have much Mozilla time these days. 

Thanks Uri!  Any improvement here would be fantastic.

    
  
Severity: normal → major
Whiteboard: orca:ugent

    
  
Whiteboard: orca:ugent → orca:urgent
Flags: blocking1.9?
Version: unspecified → Trunk
Flags: blocking1.9? → blocking1.9-

    
    

    
  
Hi Ginn, Uri: Any ideas on this bug?

    
    

    
  
Hi Ginn, Uri: Any thoughts/reasoning on why this bug is so difficult to fix?  Is there any possibility of a workaround, either in Orca or Gecko?

    
    

    
  
I'm trying to figure out how to make PresShell::CompleteMove() work with floating or absolute-positioned elements.

Meanwhile, I'm wondering what's real expectation of Ctrl+Home/End.
I guess the answer is the most top-left/bottom-right position in visual.

But it's quite possible that, after pressing Ctrl+End, pressing right arrow will make the caret jump to anywhere in the page (depends on the HTML source).
Or similar behavior when you pressing right arrow several times after pressing Ctrl+Home.
So in fact, moving caret "in visual" is not really helpful for people with sight difficulties.

On the other hand, a well-written web page should looks correct with or without css styling. In this case, we will not have the problem above, and the most top-left element is also the first element in html.

It seems making Ctrl+Home/End work "in visual" benefits everybody.

    
    

    
  
Hi Ginn!  Thanks for taking a look.  I believe the expected behavior is this:  When not in an editable area (e.g., a text area or a list of selectable items) Ctrl+Home should take you to the beginning of the entire content for the page and Ctrl+End should take you to the end of the entire content of the page.  That is, it should be independent of what is visible on the screen.  If you are in an editable area, I believe Ctrl+Home and Ctrl+End take you to the beginning and end of that area.

I think the web page for this bug tends to exhibit the proper behavior, and the test case Joanie provided (https://bugzilla.mozilla.org/attachment.cgi?id=257293) exhibits the bad behavior.

    
    

    
  
Will,

You can just copy&paste the test case into thunderbird mail editor.
I don't think ctrl+home/end should behave differently in editable area and web page area.
It would be quite confusing.

Gecko only provides very limited caret browsing function, and it's not designed as a document structure navigation.
I think it would be easier to implement document structure navigation as an extension (using AT-SPI or XPCOM) rather than redefine the keystrokes of Gecko caret browsing.


    
    

    
  
> You can just copy&paste the test case into thunderbird mail editor.
> I don't think ctrl+home/end should behave differently in editable area and web
> page area.

It looks broken there, too.  The way I reproduced this was:

1) Change my account's composition preferences to compose in HTML
2) Open the test case in Firefox.
3) Press Ctrl+A then Ctrl+C to select/copy the whole page
4) Compose a new message in Thunderbird and Ctrl+V to paste the stuff I copied

Do you have an idea about what part of the Gecko code is causing this breakage and if/how there might be a workaround?

Related to confusion -- it's definitely very confusing for users if Ctrl+Home/End work great on some pages, but then don't work on other pages where position:absolute is used.  That inconsistency is the crux of this bug.

> I think it would be easier to implement document structure navigation as an
> extension (using AT-SPI or XPCOM) rather than redefine the keystrokes of Gecko
> caret browsing.

I'm not sure we're really talking about structural navigation here.  Instead, we're just talking about using Ctrl+Home/End to position the caret at the top or bottom of the content in a page.  For some reason, position:absolute is modifying the behavior of existing functionality already provided by Gecko, and I'm just curious if you can investigate why position:absolute is causing this problem and if there is a workaround.


    
    

    
  
> I don't think ctrl+home/end should behave differently in editable area and web
> page area.

Ginn, they already do. :-)  If I'm in the "Additional Comments" entry writing  you a response and press Control+Home, I move to the top of this entry.  But if I click above it so that I'm in the document and press Control+Home, I move to the top of the entire page.

But let's ignore entries for the moment.

I agree with Will.  It's confusing that Control+Home may move you to the top of the page or it may not -- and it would take you to the top if it weren't for that position:absolute. :-)

If you can work out why this happens and fix it, that would be awesome!  Thanks Ginn!!

    
    

    
  
Will,
I misunderstood your comment #10.
"You can just copy&paste the test case into thunderbird mail editor."
I was not offering a workaround, I was trying to say, the bug exists in composer too.

Joan,
Yes, ctrl+home/end is only expected to work inside the "frame".
I meant no matter the testcase is a static page or editable, the bug is same, and we should fix it the same way.

I think we have the same expectation of Ctrl+home.
Scroll to the top, put the caret at the top-left most position.

    
    

    
  
(In reply to comment #14)
> I meant no matter the testcase is a static page or editable, the bug is same,
> and we should fix it the same way.

Yeah!  Thanks, Ginn.  I really look forward to you looking into this.
 
> I think we have the same expectation of Ctrl+home.
> Scroll to the top, put the caret at the top-left most position.

To be more pedantic, I think the proper thing is the 'beginning of the content for the page.'  So, for some locales, that might be the top right, I think.  I'm not 100% sure, though, because I only read languages that go left-to-right, top-to-bottom.

In addition, just to make sure we're also on the same page about Ctrl+bottom, it would be along the lines of 'end of the content for the page'.

Thanks again, Ginn!

    
    

    
  
I think we might need another variation of  DrillDownToSelectionFrame() for CompleteMove().

We might need to do Rect comparison, do nsPlaceholderFrame::GetRealFrameFor.



    
    

    
  
To get the beginning of the content in "visual" could be really painful, floating and absolute-positioned frame can be everywhere, which means we may need to do a full iteration.

Perhaps to use first/last selectable non-empty frame is more reasonable.

    
    

    
  
There must be performant code that does it for mouse clicks and text selection with the mouse.

    
    

    
  
In spite of  the possible performance issue, I realized it's impossible to get a fit-all standard to measure for what is the "visual" beginning/ending of the page.
Frames can have overlaps, frames can have different direction.

According to
http://www.w3.org/TR/WCAG10-CSS-TECHS/#style-alignment
Web developers is responsible to keep the order in which items appear on a screen to be same with the order they are found in the source document.

So I think it's more reasonable to use "logic" beginning/ending of the page.
The pitfall of this method is, with caret browsing on, by pressing Ctrl+Home, perhaps the result is scrolling down to the middle or end of page, because the first element has something like "position: absolute; top:1000px;"
We can't avoid thing like that unless we keep ctrl+home/end away from absolute positioned frames.

My plan is:
DrillDownToSelectionFrame (or a variation of DrillDownToSelectionFrame) should
1) try to return a SelfIsSelectable and !IsEmpty frame
2) drill down to the real frame of a placeholder frame.
If it failed to get a non-empty frame inside the real frame, it should continue from next/prev sibling of the placeholder frame. 
3) Is GetPrevSiblingFor good to use?



    
    

    
  

      
      
      
      

        Attached patch
          
          
        draft patch
        — 
          — Splinter Review
      

    


  
Use a simple deep first search, and drill down to placeholder frame.
Return the first frame that the caret can stay.

IsEmpty() is not useful for the parent frame, because the child frame can be a placeholder frame.

    
    

    
  
Would the new nsIPresShell::GetRealPrimaryFrameFor() help?

It doesn't return place holder frames -- it will return the real frame in that case.

    
    

    
  
I think it's same as nsPlaceholderFrame::GetRealFrameFor().

    
    

    
  
You're right, it's the same.

    
  
Summary: position: absolute interferes with keyboard navigation (Ctrl+Home/End) within page content → Float and position: absolute interferes with keyboard navigation (Ctrl+Home/End) within page content

    
  
Summary: Float and position: absolute interferes with keyboard navigation (Ctrl+Home/End) within page content → Float or position: absolute interferes with keyboard navigation (Ctrl+Home/End) within page content
Component: Keyboard: Navigation → User events and focus handling

    
    

    
  
Hi,

I am still able to reproduce this in latest Fx versions.



    
    

    
  
The bug assignee didn't login in Bugzilla in the last 7 months.

:hsinyi, could you have a look please?

For more information, please visit auto_nag documentation.


Assignee: ginnchen+exoracle → nobody
Flags: needinfo?(htsai)

    
    

    
  
Making the testcase editable with adding contenteditable attribute to <html>, I checked behavior of current Gecko and Blink.


On Blink, selection is moved to start/end of the text content and typing new character inserts them into start of <h1> or end of the last <p>.


On the other hand, on Gecko, selection is moved to perhaps start/end of <body> and typing new character inserts before <h3> or nothing typed after Ctrl - End.


From point of view of editor module, this is not so important because web apps using contenteditable in the wild do not use position:absolute.


Blocks: editor-blink-compat
Severity: major → S3
Flags: needinfo?(htsai)
OS: Linux → All
Priority: -- → P4

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: