Bugzilla

Gion-Andri Cantieni [:gion-andri]

Comment 3

•

8 years ago

Hello.

Any update on this issue analysis? It was reported to us by 30+ customer companies and it heavily impacts important scenarios in Polarion's Document editor. We'd appreciate response and prompt solution to this recently introduced regression.

Thank you,
Radek Krotil

Renzo de Paoli

Comment 4

•

8 years ago

Hello.

We are one of the customers Radek mentioned.

I can confirm that the issue still exists in FF51.0b (64-bit), on Win 7 & and Kubuntu 16.04.
Last version that works is FF48.0b9.

Could you please give an update on this issue, as it seriously effects our work?

Thanks in advance.

Best Regards,
Renzo de Paoli

Comment 5

•

8 years ago

I tested with MozRegression. This was the result:

>2016-12-08T22:27:31: INFO : Narrowed inbound regression window from [3bcd3c27, 9fbf850d] (4 revisions) to [31edd184, 9fbf850d] (2 revisions) (~1 steps left)
>2016-12-08T22:27:31: DEBUG : Starting merge handling...
>2016-12-08T22:27:31: DEBUG : Using url: https://hg.mozilla.org/integration/mozilla-inbound/json-pushes?changeset=9fbf850dc78d7197132a298f9ec0270c7de16a13&full=1
>2016-12-08T22:27:32: DEBUG : Found commit message:
>Bug 1213126: Enable support for webkit-prefixed CSS properties & features by default. r=heycam
> 
>2016-12-08T22:27:32: INFO : The bisection is done.
>2016-12-08T22:27:32: INFO : Stopped

Daniel, maybe you could help?

Flags: needinfo?(dholbert)

Gion-Andri Cantieni [:gion-andri]

Updated

•

8 years ago

Status: UNCONFIRMED → NEW

Ever confirmed: true

Makoto Kato [:m_kato]

Updated

•

8 years ago

Keywords: regression

Priority: P3 → P2

Ryan VanderMeulen [:RyanVM]

Updated

•

7 years ago

Blocks: 1213126

status-firefox50: --- → wontfix

status-firefox51: --- → affected

status-firefox52: --- → affected

status-firefox53: --- → affected

Comment 6

•

7 years ago

The missing span in question is:

<span class="polarion-dle-workitem-icon-container-decorations" id="polarion_icon_container" onmousedown="return false;" contenteditable="false">

(which precedes) <img id="link" src="http://almdemo.polarion.com/polarion/ria/images/linking/link.png" class="polarion-LinkAction" style="cursor: pointer !important;" title="Create Link">

Comment 7

•

7 years ago

(note, if you log in @ http://almdemo.polarion.com/polarion/#/project/SampleProject/wiki/Process%20Description, you get redirected to http://almdemo.polarion.com/polarion/wiki/skins/sidecar/xwiki.js?buildId=20160914-2236, which is kind of weird? You can navigate back to http://almdemo.polarion.com/polarion/#/project/SampleProject/wiki/Process%20Description after tho)

Comment 8

•

7 years ago

(In reply to Mike Taylor [:miketaylr] from comment #7)
> (note, if you log in @
> http://almdemo.polarion.com/polarion/#/project/SampleProject/wiki/
> Process%20Description, you get redirected to
> http://almdemo.polarion.com/polarion/wiki/skins/sidecar/xwiki.
> js?buildId=20160914-2236, which is kind of weird? You can navigate back to
> http://almdemo.polarion.com/polarion/#/project/SampleProject/wiki/
> Process%20Description after tho)

Hi Mike.

Thank you for noting this problem. It's an issue in redirect that is supposed to bring the user to recently visited page. It will be fixed in Polarion 17 to be released in March 2017.

However, this issue is not related to the problem with our problem with missing span.

Best regards,
Radek

Comment 9

•

7 years ago

In the past, bustage like this has been the result of some kind of "feature detection" looking for a WebKit-prefixed DOM API, and then deciding to take one codepath. That would normally explain why flipping the pref off fixes the issue.

However, I don't see anything super obvious after quickly poking at the site.

Dennis, would you be able to take a closer look? See Comment #2 for test credentials, and Comment #7 if you get confused by the redirect after logging in.

Flags: needinfo?(dschubert)

Updated

•

7 years ago

Flags: needinfo?(dholbert)

Comment 10

•

7 years ago

I looked into this a bit (finally! sorry for the delayed needinfo response), and I think I got to the bottom of it.

The element in question (the span noted in comment 6) is styled with "-webkit-user-select: none", in this rule:

> .polarion-dle-workitem-icon-container-decorations {
>   display: block;
>   text-align: right;
>   width: 100px;
>   height: 0px;
>   margin-left: -144px;
>   -webkit-user-select: none;
> }
Source: http://almdemo.polarion.com/polarion/gwt/gwt/polarion/dle_document.css?buildId=20160914-2236

When we didn't support -webkit prefixed CSS, that "-webkit-user-select" line had no effect. Now, it blocks the <span> from being selected (and copied).  Something like that, anyway.

Anyway -- if you *want* the span to be selectable & copypastable, it's easy to fix -- just remove that "-webkit-user-select:none" line from your CSS!  Or, if you really do want it there for some specific effect in webkit-derived browsers, you could prevent it from busting Firefox by adding "-moz-user-select: initial" immediately after it.  This will cancel out its effects, specifically in Firefox.

Radek, could you (or someone at Polarion) give that a try and see if that addresses the issue for you?  Thanks!

Flags: needinfo?(radek.krotil)

Updated

•

7 years ago

Flags: needinfo?(dschubert)

Comment 11

•

7 years ago

A few notes from a compatibility/correctness perspective:
 - It seems we're excluding the <span>-parent, but *including* its child <img> elements in the copied selection.  That seems like a bug.  The "user-select:none" value is supposed to prevent selection of "the element and sub-elements" per https://developer.mozilla.org/en-US/docs/Web/CSS/user-select

 - Comparing to Chrome: in a local reduced testcase that I came up with, Chrome includes neither the <span> nor the <img> in the clipboard. BUT, on the live site, it includes both. (despite the presence of -webkit-user-select: none.) Not sure why; I'll probably try to re-reduce a testcase to figure out the difference.

Comment 12

•

7 years ago

i-meant-initial-not-none

(In reply to Daniel Holbert [:dholbert] from comment #11)
> A few notes from a compatibility/correctness perspective:
>  - It seems we're excluding the <span>-parent, but *including* its child
> <img> elements in the copied selection.  That seems like a bug.

Aha! Actually, the MDN content is just out of date -- we're exactly right in this behavior. The spec says this about "user-select:none":
  # If the element has descendants on which 'user-select'
  # does not compute to 'none', these descendants must be
  # included in a selection extending across the element
https://drafts.csswg.org/css-ui-4/#valdef-user-select-none

In Firefox, the <img> elements do not have "user-select:none" (because they're not specified as having that value, and "user-select" is not inherited).  So they get included in the selection, even though their parent does not.

In Chrome, Chrome's devtools show me that the <img> elements *do* have "user-select:none", inherited from the <span>. That is a bug. So, that's perhaps why I'm seeing them get completely-excluded in some cases.

The spec does also mention this in its 'user-select:none' section:
  # Note: As of the time of writing, experimental implementations do not all
  # behave like this. Firefox does. Chrome and Safari almost do: [...]

So there's some known incompatibilities here, and Firefox is closest to matching the spec (according to the spec-authors).

SO: it seems there's unlikely to be an actual Firefox defect hiding here (--> Reclassifying as Tech Evangelism), and the best way forward is for Polarion to make one of two possible remedies:
 (1) if Polarion does not need this "-webkit-user-select" styling in webkit-derived browsers, then just remove that line.
 (2) if Polarion DOES need this "-webkit-user-select" styling in webkit-derived browsers for some reason, then suppress it in Firefox with "-moz-user-select:none".
(See comment 10 for more details.)

(If they do indeed need this declaration and go with option #2, then I'm also curious if Firefox users end up with a suboptimal experience from missing out on whatever benefit that declaration is granting to webkit users...)

Radek: hopefully the above is clear, and apologies again for taking a little while to get to this. Please let me know if this works & if you need any additional help/clarification!

Component: Editor → Desktop

Product: Core → Tech Evangelism

Version: 49 Branch → Firefox 49

Comment hidden (obsolete)

(In reply to Daniel Holbert [:dholbert] from comment #12)
> In Chrome, Chrome's devtools show me that the <img> elements *do* have
> "user-select:none", inherited from the <span>. That is a bug. So, that's
> perhaps why I'm seeing them get completely-excluded in some cases.

(I filed https://bugs.chromium.org/p/chromium/issues/detail?id=678123 on this, BTW. Though this doesn't explain why these elements get included in the clipboard in Chrome in the live site -- they're not supposed to, and that's a distinct Chrome bug.)

Comment 14

•

7 years ago

Thanks Daniel!

Whiteboard: [sitewait]

Comment 15

•

7 years ago

(In reply to Daniel Holbert [:dholbert] from comment #12)
> >  - It seems we're excluding the <span>-parent, but *including* its child
> > <img> elements in the copied selection.  That seems like a bug.
> 
> Aha! Actually, the MDN content is just out of date -- we're exactly right in
> this behavior. The spec says this about "user-select:none":
>   # If the element has descendants on which 'user-select'
>   # does not compute to 'none', these descendants must be
>   # included in a selection extending across the element

(Following up on this slightly: we do actually have a bug here with respect to the current spec -- I filed bug 1328475. But I don't think that really impacts this particular Polarion site much, except that it means we really should be excluding the <img> elements *as well as* the <span>, with the current Polarion styling.)

Summary: Clipboard is modified when cut/copy HTML → Clipboard contents are different when you cut/copy HTML at Polarion, depending on webkit prefix support

Comment 16

•

7 years ago

> SO: it seems there's unlikely to be an actual Firefox defect hiding here
> (--> Reclassifying as Tech Evangelism), and the best way forward is for
> Polarion to make one of two possible remedies:
>  (1) if Polarion does not need this "-webkit-user-select" styling in
> webkit-derived browsers, then just remove that line.
>  (2) if Polarion DOES need this "-webkit-user-select" styling in
> webkit-derived browsers for some reason, then suppress it in Firefox with
> "-moz-user-select:none".
> (See comment 10 for more details.)
> 
> (If they do indeed need this declaration and go with option #2, then I'm
> also curious if Firefox users end up with a suboptimal experience from
> missing out on whatever benefit that declaration is granting to webkit
> users...)
> 
> Radek: hopefully the above is clear, and apologies again for taking a little
> while to get to this. Please let me know if this works & if you need any
> additional help/clarification!

Hi Daniel.

Thank you so much for your detailed analysis! Really interesting read. I can confirm that removal of the specific style fixes the problem with missing part of the selection for copy.

Next I'll follow-up with our developer to fix our CSS and figure out why that particular style is needed in the first place. Also we have a workaround now, i.e. setting Firefox config property layout.css.prefixes.webkit=false.

This ticket can be closed now.

Thanks again,
Radek

Flags: needinfo?(radek.krotil)

Comment 17

•

7 years ago

> Also we have a workaround now,
i.e. setting Firefox config property layout.css.prefixes.webkit=false.

Just be aware that flipping that pref (or asking your users to) will break sites that were otherwise fixed by that pref. :/

Comment 18

•

7 years ago

(In reply to Mike Taylor [:miketaylr] from comment #17)
> > Also we have a workaround now,
> i.e. setting Firefox config property layout.css.prefixes.webkit=false.
> 
> Just be aware that flipping that pref (or asking your users to) will break
> sites that were otherwise fixed by that pref. :/

That's clear, Mike. But Polarion is business critical tool for our users and this settings with switch to behavior of Firefox 48 and earlier. So I don't anticipate big impact on our users and this workaround is just temporary until we can provide fix in our app.

Thanks,
Radek

Comment 19

•

7 years ago

Thanks, Radek!  We're hoping the developer can fix the CSS quickly, so that you don't have to rely on the about:config tweak for too many users.  If you're wanting to be cautious due to concerns about unforseen-side-effects, then I'd suggest just making this extremely-low-risk Firefox-specific CSS fix -- just adding this line:
  -moz-user-select:initial;
...at the end of your .polarion-dle-workitem-icon-container-decorations { ... } style rule in the stylesheet linked in comment 10 (after the -webkit-user-select line).  This will have zero impact on non-Firefox browsers (since browsers skip CSS properties that they don't recognize), and it'll restore the old behavior of this element in Firefox.

(IMPORTANT NOTE: in comment 12 I misspoke -- I *intended* to suggest "-moz-user-select:initial" in my option (2) there, but I accidentally mistyped and said "none" [which is really the problematic value].  The point is to reset this property to its *initial* value (in Firefox).  Sorry for any confusion that caused/causes.)

> This ticket can be closed now.

Thanks! We've reclassified this as Tech Evangelism (i.e. compatibility fixes for web sites), and we tend to leave those bugs open until it's been confirmed that the site is working as-expected again.  So we'll leave this open for the time being -- but please do give us a heads-up when the CSS has been tweaked to address this, and we'll close this at that point.

Comment 20

•

7 years ago

(In reply to Daniel Holbert [:dholbert] from comment #19)
> Thanks, Radek!  We're hoping the developer can fix the CSS quickly, so that
> you don't have to rely on the about:config tweak for too many users.  If
> you're wanting to be cautious due to concerns about unforseen-side-effects,
> then I'd suggest just making this extremely-low-risk Firefox-specific CSS
> fix -- just adding this line:
>   -moz-user-select:initial;
> ...at the end of your .polarion-dle-workitem-icon-container-decorations {
> ... } style rule in the stylesheet linked in comment 10 (after the
> -webkit-user-select line).  This will have zero impact on non-Firefox
> browsers (since browsers skip CSS properties that they don't recognize), and
> it'll restore the old behavior of this element in Firefox.
> 
> (IMPORTANT NOTE: in comment 12 I misspoke -- I *intended* to suggest
> "-moz-user-select:initial" in my option (2) there, but I accidentally
> mistyped and said "none" [which is really the problematic value].  The point
> is to reset this property to its *initial* value (in Firefox).  Sorry for
> any confusion that caused/causes.)
> 
> > This ticket can be closed now.
> 
> Thanks! We've reclassified this as Tech Evangelism (i.e. compatibility fixes
> for web sites), and we tend to leave those bugs open until it's been
> confirmed that the site is working as-expected again.  So we'll leave this
> open for the time being -- but please do give us a heads-up when the CSS has
> been tweaked to address this, and we'll close this at that point.

All your points are clear, Daniel, but situation is unfortunately not that simple. Almdemo is only our test drive server, where prospects can try Polarion features. But Polarion is a web application that is installed in hundreds of on-premises deployments. We release new version every 3 months and it may take several releases until our affected customers update to the next version that will contain the fix. Until then specific users that need this use case and use Firefox will be either suffering from this issue that may impact their productivity, or revert to the old behavior for FF 48 and earlier to workaround that issue.

Nevertheless, I'll ensure that our documentation contains note that if such particular configuration change was applied, it should ve reverted with the next version.

Radek