form controls should get focus when a URI points to them (with a fragment identifier)
Categories
(Core :: Layout: Form Controls, enhancement)
Tracking
()
Tracking | Status | |
---|---|---|
firefox100 | --- | fixed |
People
(Reporter: annevk, Assigned: emilio)
References
(Blocks 2 open bugs, )
Details
(4 keywords)
Attachments
(3 files)
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.
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).
Reporter | ||
Comment 2•20 years ago
|
||
Internet Explorer behaves the same as Mozilla in this testcase. "You can keep hitting enter."
Comment 3•20 years ago
|
||
So IE focuses some focusable things that are anchor targets but not others?
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.
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.
Comment 6•17 years ago
|
||
Anne, does IE focus anything that's focusable and the target of an anchor?
Comment 7•10 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.
Updated•9 years ago
|
Comment hidden (mozreview-request) |
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 = ...
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?
Comment hidden (mozreview-request) |
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.
Comment 13•8 years ago
|
||
I guess I can live with that.
Updated•8 years ago
|
Updated•8 years ago
|
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
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
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.
Comment 18•7 years ago
|
||
Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)
Updated•7 years ago
|
Comment 19•6 years ago
|
||
Instead of backing out and leaving this bug as-is for 3 years, is there a plan to get this fixed? The fix seems reasonable to me?
Comment 20•6 years ago
|
||
The fix was failing tests. So either the fix or the tests (less likely) presumably needs to be changed.
No one has stepped up to figure out which of the two needs to happen, much less how exactly it should happen. You are of course free to step up and do that; that would help immensely in terms of getting this fix checked in.
Assignee | ||
Comment 21•6 years ago
|
||
FWIW, here's a rebased patch, just in case it's green:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=858c4ccfb9b2b2432be6352ffca0bb032504685f
Comment 22•3 years ago
|
||
The bug assignee didn't login in Bugzilla in the last 7 months.
:emilio, could you have a look please?
For more information, please visit auto_nag documentation.
Assignee | ||
Updated•3 years ago
|
Assignee | ||
Comment 23•3 years ago
|
||
Co-authored-by: Takeshi Kurosawa <taken.spc@gmail.com>
Updated•3 years ago
|
Comment 24•3 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
Comment 25•3 years ago
|
||
bugherder |
Description
•