form controls should get focus when a URI points to them (with a fragment identifier)

NEW
Assigned to

Status

()

--
enhancement
14 years ago
8 months ago

People

(Reporter: annevk, Assigned: taken.spc)

Tracking

(Blocks: 1 bug, 4 keywords)

Trunk
parity-chrome, parity-ie, parity-safari, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

14 years ago
Simple example:
 <http://www.mozilla.org/#q>

If anyone cares, Internet Explorer supports this. It is probably obvious, but if
the form control gets focus it should match :focus as well.
Does IE focus an anchor that is the target of a URI reference too?  That is, if
you have <a name="q">, does that get focused?

Specifically, see the code at
http://lxr.mozilla.org/seamonkey/source/layout/base/nsPresShell.cpp#3990 -- that
explicitly focuses the document while putting the caret at the anchor (which can
be any node that has a relevant ID, of course).
(Reporter)

Comment 2

14 years ago
Created attachment 170385 [details]
testcase

Internet Explorer behaves the same as Mozilla in this testcase. "You can keep
hitting enter."
So IE focuses some focusable things that are anchor targets but not others?
(Reporter)

Comment 4

14 years ago
It seems that recent nightlies behave different from Internet Explorer in
attachment 170385 [details]. Firefox 1.0 acts identical however. I am not sure if that is
a regression or so, but if, it is a separate bug.

Updated

14 years ago
Blocks: 83552
See bug 258514 for the history here.  Looks like this behavior is on purpose?  I'm not sure I follow why, though.
Anne, does IE focus anything that's focusable and the target of an anchor?

Comment 7

4 years ago
I can confirm this issue (10 years later) with Firefox 35 on OSX.
Live test case: http://medialize.github.io/ally.js/tests/browser-bugs/gecko-focus-target.html#gustav
The :target element is to receive focus on page load as defined in HTML5: http://www.w3.org/TR/html5/browsers.html#scroll-to-fragid
Blink, WebKit and Trident behave correctly.
(Assignee)

Updated

3 years ago
Whiteboard: [partiy-chrome][parity-ie]
Comment hidden (mozreview-request)

Comment 9

2 years ago
mozreview-review
Comment on attachment 8783489 [details]
Bug 277178 - Move focus to a fragment identifier (#fragment) if it's focusable;

https://reviewboard.mozilla.org/r/73268/#review71042

::: layout/base/nsPresShell.cpp:3095
(Diff revision 1)
>  
>      // Even if select anchor pref is false, we must still move the
>      // caret there. That way tabbing will start from the new
>      // location
>      RefPtr<nsIDOMRange> jumpToRange = new nsRange(mDocument);
> -    while (content && content->GetFirstChild()) {
> +    nsIContent *selectionTarget = content;

nsIContent* selectionTarget = ...

::: layout/base/nsPresShell.cpp:3128
(Diff revision 1)
> +        fm->SetFocus(element, 0);
> +      } else {
> -      nsCOMPtr<mozIDOMWindowProxy> focusedWindow;
> +        nsCOMPtr<mozIDOMWindowProxy> focusedWindow;
> -      fm->GetFocusedWindow(getter_AddRefs(focusedWindow));
> +        fm->GetFocusedWindow(getter_AddRefs(focusedWindow));
> +
> +        nsPIDOMWindowOuter *win = mDocument->GetWindow();

nsPIDOMWindowOuter* win = ...

Comment 10

2 years ago
mozreview-review
Comment on attachment 8783489 [details]
Bug 277178 - Move focus to a fragment identifier (#fragment) if it's focusable;

https://reviewboard.mozilla.org/r/73268/#review71044

Could you please still test how different browsers work when fragment navigation happens in iframes. Does the focus move from some focused element in parent document to the child document's element?
Attachment #8783489 - Flags: review?(bugs) → review+
Comment hidden (mozreview-request)
(Assignee)

Comment 12

2 years ago
mozreview-review-reply
Comment on attachment 8783489 [details]
Bug 277178 - Move focus to a fragment identifier (#fragment) if it's focusable;

https://reviewboard.mozilla.org/r/73268/#review71044

> Could you please still test how different browsers work when fragment navigation happens in iframes. Does the focus move from some focused element in parent document to the child document's element?

Different browsers have different ways...

Chrome Canary 54

- Moves the focus from an element in parent to an element in child iframe
- Update iframe's activeElement

WebKit Nightly

- Don't move the focus from an element in parent to an element in child iframe
- Update iframe's activeElement

Edge

- Don't move the focus from an element in parent to an element in child iframe
- Don't update iframe's activeElement

Behavoir of Firefox with this change is similar to Chrome Canary 54.
I guess I can live with that.
(Assignee)

Updated

2 years ago
Keywords: checkin-needed
OS: Windows XP → All
Hardware: x86 → All
Whiteboard: [partiy-chrome][parity-ie] → [partiy-chrome][parity-ie][parity-safari]
Assignee: nobody → taken.spc

Comment 14

2 years ago
Pushed by ryanvm@gmail.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/254e306bc62c
Move focus to a fragment identifier (#fragment) if it's focusable. r=smaug
Keywords: checkin-needed
Backed out for being the most-likely cause of the below test_sessionhistory.html permafail.
https://treeherder.mozilla.org/logviewer.html#?job_id=34910713&repo=mozilla-inbound

Comment 16

2 years ago
Backout by ryanvm@gmail.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/12c6aa2ffee4
Backed out changeset 254e306bc62c for likely causing test_sessionhistory.html to permafail.

Updated

2 years ago
Duplicate of this bug: 1317673
Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)
Keywords: parity-ie, parity-safari
Whiteboard: [partiy-chrome][parity-ie][parity-safari] → [partiy-chrome]
Keywords: parity-chrome
Whiteboard: [partiy-chrome]
You need to log in before you can comment on or make changes to this bug.