Anne (:annevk) Reporter
	Description • 20 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.

	Boris Zbarsky [:bzbarsky]
	Comment 1 • 20 years ago

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).

	Anne (:annevk) Reporter
	Comment 2 • 20 years ago

Internet Explorer behaves the same as Mozilla in this testcase. "You can keep
hitting enter."

	Boris Zbarsky [:bzbarsky]
	Comment 3 • 20 years ago

So IE focuses some focusable things that are anchor targets but not others?

	Anne (:annevk) Reporter
	Comment 4 • 20 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.

	Boris Zbarsky [:bzbarsky]
	Comment 5 • 17 years ago

See bug 258514 for the history here.  Looks like this behavior is on purpose?  I'm not sure I follow why, though.

	Boris Zbarsky [:bzbarsky]
	Comment 6 • 17 years ago

Anne, does IE focus anything that's focusable and the target of an anchor?

	Rodney Rehm
	Comment 7 • 9 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.

	Olli Pettay [:smaug][bugs@pettay.fi]
	Comment 9 • 8 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 = ...

	Olli Pettay [:smaug][bugs@pettay.fi]
	Comment 10 • 8 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?

	Takeshi Kurosawa :takenspc
	Comment 12 • 8 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.

	Olli Pettay [:smaug][bugs@pettay.fi]
	Comment 13 • 8 years ago

I guess I can live with that.

	Pulsebot
	Comment 14 • 8 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

	Ryan VanderMeulen [:RyanVM]
	Comment 15 • 8 years ago

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

	Pulsebot
	Comment 16 • 8 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.

	Jonathan Watt [:jwatt]
	Comment 18 • 6 years ago

Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)

	Pulsebot
	Comment 24 • 2 years ago

Pushed by ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/2444006ef57f
Move focus to a fragment identifier (#fragment) if it's focusable. r=smaug