Closed Bug 1094133 Opened 10 years ago Closed 9 years ago

In "Suggested Posts" on Facebook, you cannot select

Categories

(Core :: Layout: Form Controls, defect)

31 Branch
x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: mozilla, Unassigned)

Details

User Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20040914 Firefox/0.10 Build ID: 20140916104755 Steps to reproduce: 1. Logged into facebook 2. Scrolled down until I saw a "Suggested post" 3. Attempted to select the test in the Suggested post (below the picture) Actual results: A faint gray box of the shape of the picture + text stuck to my mouse pointer, and moved along with it while I was trying to select Expected results: Selection should have proceeded normally (i.e. text swept by my mouse should have been highlighted and available for pasting elsewhere) Even pressing windowskey+alt along with the left mouse button didn't help (this help for selecting part of a link text)
User Agent: Mozilla/5.0 ((X11; Linux i686; rv:46.0) Gecko/20100101 Firefox/46.0 Nightly 46.0a1 Build ID:20160104030217 Alain Knaff, Thank you for taking time to report this. Are you still having the same issue in the latest version ? I cannot reproduce in the current version.
Component: Untriaged → Layout: Form Controls
Flags: needinfo?(mozilla)
Product: Firefox → Core
Indeed, facebook no longer has "suggested posts", but the bad behavior can now be seen with "link"s. Just search for "shared a link" on your Facebook feed, and attempt to select the text below the picutre. Just tried this now: the problem still exists! It also happens for sponsored posts.
Flags: needinfo?(mozilla)
Alain, thanks for your information. Yes, I can reproduce it now. It is also reproducible in other browsers too. Not sure if this is a browser or Facebook issue.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(mozilla)
(In reply to Alain Knaff from comment #2) > Just search for "shared a link" on your Facebook feed, and attempt to select > the text below the picutre. > > Just tried this now: the problem still exists! This seems to be an intentional design decision that Facebook has made. They place a visually-transparent <a> element (a link) on top of the full rectangular area of the post (over the picture and the text), so anywhere you click, you're clicking the transparent <a>, not the text. (You can see this area if you click on the text and drag -- the <a> as a whole gets dragged, and you can see its borders) The image floats above this <a> element (and has its own separate linkification) because its parent has "z-index: 1". But the text does not.) So, I think I'm going to resolve this as INVALID as a Firefox/Mozilla bug, since we're rendering the site correctly and other browsers agree (per comment 3). But please do report this to Facebook, if it bothers you!
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → INVALID
Flags: needinfo?(mozilla)
(In reply to Daniel Holbert [:dholbert] from comment #4) > (In reply to Alain Knaff from comment #2) > > Just search for "shared a link" on your Facebook feed, and attempt to select > > the text below the picutre. > > > > Just tried this now: the problem still exists! > > This seems to be an intentional design decision that Facebook has made. They > place a visually-transparent <a> element (a link) on top of the full > rectangular area of the post (over the picture and the text), so anywhere > you click, you're clicking the transparent <a>, not the text. > > (You can see this area if you click on the text and drag -- the <a> as a > whole gets dragged, and you can see its borders) > > The image floats above this <a> element (and has its own separate > linkification) because its parent has "z-index: 1". But the text does not.) Interesting. Thanks for this explanation. This gives me a handy workaround: Inspect element, and then display: none; :-) > > So, I think I'm going to resolve this as INVALID as a Firefox/Mozilla bug, > since we're rendering the site correctly and other browsers agree (per Does this mean that Firefox no longer will patch other security holes either, as anybody who'd exploit these holes would do so intentionally? I hope you understand that I'm a bit worried about the prospect of this. Firefox should not have such a cavalier attitude on clickjacking... > comment 3). But please do report this to Facebook, if it bothers you! ... and maybe the Cologne victims should ask their fondlers nicely to stop, rather than complaining to police/the papers? :-) IMHO, browsers should have a duty to protect the user against malicious and/or obnoxious sites (as long as technically feasible).
(In reply to Alain Knaff from comment #5) > This gives me a handy workaround: Inspect element, and then display: none; > :-) Yup, that should work (though of course it makes that area no longer linked) > Does this mean that Firefox no longer will patch other security holes > either, as anybody who'd exploit these holes would do so intentionally? Sorry, the rest of this comment is a bit ridiculous & over the top. Yes, we'll fix security holes. Yes, we strive to prevent sites from doing malicious things. I don't think any of that is relevant here. If you have a real clickjacking vulnerability to report, please do so. Facebook putting its own transparent <a> element over its own content is not a clickjacking vulnerability.
(Expanding on comment 6: as I understand it, clickjacking is about things like Site A tricking you into clicking a particular button *on Site B* -- e.g. evil.com having a nearly-transparent iframe for yourbank.com or gmail.com, superimposed with a click-the-monkey game. One mitigation that blocks that is "x-frame-options", which lets yourbank.com & gmail.com refuse to ever appear in an <iframe>. I'll bet there are other mitigations as well, though I'm not familiar with them. Anyway, this attack scenario is *completely* different from "Site A tricks you into accidentally clicking something on the very same site", which is what's happening here.)
(In reply to Daniel Holbert [:dholbert] from comment #6) > (In reply to Alain Knaff from comment #5) > > This gives me a handy workaround: Inspect element, and then display: none; > > :-) > > Yup, that should work (though of course it makes that area no longer linked) Not actually a problem. This is mostly useful in cases where the link goes to a paywall or is otherwise broken (which unfortunately happens more and more often on facebook...). In that case, for news "links", the standard operating procedure is to copy-paste the headline into google and find *other* papers who have the same story, but in a readable format. Worked great... until facebook managed to block copy-paste with their transparent <a> rectangle :-( > > > Does this mean that Firefox no longer will patch other security holes > > either, as anybody who'd exploit these holes would do so intentionally? > > Sorry, the rest of this comment is a bit ridiculous & over the top. Yes, Is that your way of dealing with criticism? Calling it "ridiculous"? No wonder Firefox is losing more and more market share to Chrome and the likes... > we'll fix security holes. Yes, we strive to prevent sites from doing > malicious things. I don't think any of that is relevant here. Why do you think it is not relevant? > > If you have a real clickjacking vulnerability to report, please do so. > Facebook putting its own transparent <a> element over its own content is not > a clickjacking vulnerability. But still very obnoxious. It should not be this easy for a malicious site operator to block standard interaction with his site (such as copy-paste).
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
(In reply to Alain Knaff from comment #8) > Worked > great... until facebook managed to block copy-paste with their transparent > <a> rectangle :-( Again, please report this issue to Facebook! Your title-copypaste use case is quite legitimate, and it's entirely possible that this was semi-accidental on their part. > Is that your way of dealing with criticism? Calling it "ridiculous"? If comment 5 is your way of expressing criticism, then yes. > Why do you think it is not relevant? Because this is not a security hole and it is not clickjacking. See comment 7. > But still very obnoxious. It should not be this easy for a malicious site > operator to block standard interaction with his site (such as copy-paste). I understand that you feel that way. Sorry, Mozilla simply does not have the resources to police how sites present their own content or forcing sites to stop being "obnoxious". Security issues are one thing; blocking you from copying text is another. (Side note: there are entirely legitimate and non-annoying use-cases for doing things like what Facebook is doing & playing tricks with invisible click-targets -- e.g. GitHub's "add an attachment" link has a hidden <input type="file"> button under the hood. Too much nannying would break stuff like that.) I'm going to direct you to the Bugzilla etiquette guidelines (particularly #2 and #3, RE your comment 5): https://bugzilla.mozilla.org/page.cgi?id=etiquette.html Please review those, and please direct any further concerns about this Facebook design issue to Facebook.
Status: REOPENED → RESOLVED
Closed: 9 years ago9 years ago
Resolution: --- → INVALID
(For the record: I reached out to a former colleague who works at Facebook who may be able to get this addressed on their end. I submitted this screencast to him, demonstrating the bug & local hacky workaround: https://people.mozilla.org/~dholbert/facebook_text_unselectable.ogv )
(In reply to Daniel Holbert [:dholbert] from comment #10) > (For the record: I reached out to a former colleague who works at Facebook > who may be able to get this addressed on their end. I submitted this > screencast to him, demonstrating the bug & local hacky workaround: > https://people.mozilla.org/~dholbert/facebook_text_unselectable.ogv ) Thanks for your effort. In the meantime, myself have reported the problem using Facebook's "Report a Problem" menu option. But probably you will have more chances at getting things changed :-)
You need to log in before you can comment on or make changes to this bug.