1445191 - Unusual SvgMatrix values on transition out of fullscreen

Status: RESOLVED INCOMPLETE

(Firefox :: Untriaged, defect)

Description

[stuart]

Attachment: getScreenCTM.txt

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.167 Safari/537.36

Steps to reproduce:

Launch application and enter into lesson mode (which transitions into fullscreen).
Drag an image sprite into one of several target locations. 
Click [ESC] to exit fullscreen. 
Drag an image sprite into one of several target locations. 


Background (more detail in attached file): 

I have an application which goes into fullscreen to present SVG-based interactive lessons, which involve dragging image sprites into target locations. I determine if the drop point is inside the target location, and act according to the response. 

Because user actions in the browser can result in dropping out of fullscreen, it's good for the lessons to continue to function in the event of an unexpected fullscreen exit. On MacOS, this works as expected in Chrome and Safari, but fails in Firefox. I suspect this is due to differences in the implementation of SVGGraphicsElement.getScreenCTM().



Actual results:

On first drag (fullscreen), sprite snaps to a specified point in the target location. 
On second drag (normal), sprite snaps back to its starting location. 


Expected results:

On first drag (fullscreen), sprite snaps to a specified point in the target location. 
On second drag (normal), sprite snaps to a specified point in the target location.

Comment 1

[Robert Longson [:longsonr]]

Please create a minimal complete and runnable example, ideally without using any libraries. Otherwise we've no idea what you're doing.

Comment 2

[stuart]

I think it's practically impossible to create a "minimal complete and runnable example" without libraries. This is in a complex AngularJS application, and as mentioned used svg.js and svg.draggable.js libraries for SVG management. 

I may be able to provide login access to the actual application.

Comment 3

[Robert Longson [:longsonr]]

Up to you. We're highly unlikely to investigate it if you don't though.

Comment 4

[stuart]

It's unclear from your reply - unlikely to investigate if I don't create a minimal repro not using libraries? Is login access to the application with specific repro steps provided not something you'd consider for investigation? 

It would likely take me multiple days to create a minimal functional repro. My boss isn't going to approve that time, he would rather accept that FF has a bug that breaks our app in this scenario.

Comment 5

[stuart]

FYI the maintainer of svg.draggable.js has indicated that his library has code to work around the vagaries of getScreenCTM implementations across browsers. Here's the related issue: 

https://github.com/svgdotjs/svg.draggable.js/issues/78

Comment 6

[Robert Longson [:longsonr]]

I wouldn't be interested in debugging your entire site from a login and I suspect none of the other developers would either.

Marking incomplete as no testcase is likely to appear. Feel free to reopen if you should decide to provide one.

Comment 7

[stuart]

"I wouldn't be interested in debugging your entire site from a login"

I didn't suggest "debugging your entire site". I can provide specific repro steps in a much shorter amount of time than I could possibly-maybe create a minimal repro for the issue at hand. 

But if y'all don't care to try to investigate a bug if I don't spend days building a repro, I'll recommend to my CTO and CEO that we deprioritize Firefox since there's minimal interest on the part of Mozilla to look into this issue.

Comment 8

[Jonathan Watt [:jwatt]]

This is a case of necessary prioritization, not "we don't care".

Debugging bugs in live apps with a bunch of indirection through various libraries is very often a huge time sink (could be days, as you say) since it often involves figuring out and debugging a lot of unfamiliar code (your code, how its using the libraries, the libraries themselves). More often than not we typically find the bug is in this code, and that we've wasted our time. It makes more sense for us to focus limited resources on bugs that we know are in our code and have testcases that we can investigate and fix efficiently (of which there are more than enough to fill our time).

Since what you're primarily consuming is the libraries, the best way to proceed here is generally to reach out to the library authors first. They know and can debug their code time efficiently, and since libraries usually try to smooth over browser differences they're usually interested regardless of whether a bug is in their code or is a browser bug. Hopefully if browser bugs are found they'll also be reported to the appropriate vendor.

Comment 9

[stuart]

Thanks for the reply, Jonathan. Your response feels a lot less generally dismissive, and gives me a little sense that maybe someone there does care. 

> Debugging bugs in live apps with a bunch of indirection through various
> libraries is very often a huge time sink (could be days, as you say) 

FWIW, I said it could take days to create a minimal repro. It took me at most a few hours of debugging to determine that the issue is in getScreenCTM. I seriously doubt it would take any decent developer days to debug a situation, particularly when given detailed repro steps and lines for breakpoints. 

> Since what you're primarily consuming is the libraries, the best way to
> proceed here is generally to reach out to the library authors first. 

I did that prior to contacting Mozilla. 

https://github.com/svgdotjs/svg.draggable.js/issues/78

> Hopefully if browser
> bugs are found they'll also be reported to the appropriate vendor.

I submitted a bug with detailed information about vendor differences because the problematic call is in vendor code, which I determined / verified after interaction with the library author.