Closed Bug 1521568 Opened 6 years ago Closed 6 years ago

Can't drag downloaded PDF into new tab

Categories

(Firefox :: New Tab Page, defect, P1)

Product:
Firefox
Component:
New Tab Page
Version:
66 Branch
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Firefox 66
Iteration:
66.4 - Jan 21 - 27
Tracking Flags:
Tracking Status
firefox-esr60 --- unaffected
firefox64 --- unaffected
firefox65 --- unaffected
firefox66 --- fixed

People

(Reporter: overholt, Assigned: rrosario)

References

Details

(Keywords: github-merged, regression)

Attachments

(1 file)

Link to GitHub pull-request: https://github.com/mozilla/activity-stream/pull/4721
52 bytes, text/x-github-pull-request
Details | Review

STR:

  1. download a PDF
    1a. go to https://www150.statcan.gc.ca/n1/en/pub/12-581-x/12-581-x2008001-eng.pdf?st=P_7a_M8l
    1b. click the download icon and save it
  2. open a new, blank tab
  3. click the downloads icon, drag the PDF you just downloaded into the content area of the new tab

Expected:

  • pdfjs opens the PDF

Actual:

  • you get an "international no" cursor modifier thing

mozregression pointed me to bug 1519303 as what regressed this.

In case it's platform-specific, I tested this on Windows 10.

Blocks: 1519303
No longer depends on: 1519303

The problem is reproducible with not only pdf but also txt and heml file.

And matters worse, drag & drop onto empty area of NewTab from Desktop/Explorer, unable to open a local file.

status-firefox64: --- → unaffected
status-firefox65: --- → unaffected
status-firefox-esr60: --- → unaffected

In Bug 1520697 we started listening to drop events in the search box. For some reason, that change causes this bug where you can no longer drop a file onto the page to open it. I'll look into it. Thanks!

Assignee: nobody → rrosario
Iteration: --- → 66.4 - Jan 21 - 27
Priority: -- → P1

I wonder if this is related to bug 1503632 where turns out adding a mouse listener, react decided to add it globally resulting in high cpu. So maybe here, react is adding a drop listener and deciding it doesn't need to forward to search box?

See Also: → 1503632

(In reply to Ed Lee :Mardak from comment #3)

I wonder if this is related to bug 1503632 where turns out adding a mouse listener, react decided to add it globally resulting in high cpu. So maybe here, react is adding a drop listener and deciding it doesn't need to forward to search box?

This was my first thought too but it wasn't the issue. All our top sites are drop targets too.

Turns out if you add a contenteditable to a page, the browser stops accepting dropped files. I was able to reproduce the issue with just:

<!doctype html>
<html>
<body>
<div contenteditable style="display:none;"></div>
</body>
</html>

Changing the contenteditable to an invisible <input type="text"/> fixes the issue. Browser bug?

See Also: → 1521984
Keywords: github-merged
Blocks: 1522752

https://hg.mozilla.org/mozilla-central/rev/9d660bf33923

Status: NEW → RESOLVED
Closed: 6 years ago
status-firefox66: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 66
QA Whiteboard: [good first verify]

I have reproduced this bug with Nightly 66.0a1 (2019-01-21) on Windows 10, 64 Bit. This fix of this bug is verified with latest Beta 66.0b5!

Build ID : 20190204181317
User Agent : Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0

QA Whiteboard: [good first verify] → [good first verify] [bugday-20190206]
Component: Activity Streams: Newtab → New Tab Page
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: