Closed Bug 403217 Opened 12 years ago Closed 12 years ago

Drag & drop Russian text to the search/location bar is broken

Categories

(Core :: Drag and Drop, defect, P2)

x86
Windows XP
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: egor.pelevin, Assigned: enndeakin)

References

Details

(Keywords: regression)

Attachments

(1 file, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2pre) Gecko/2007110805 Minefield/3.0b2pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2pre) Gecko/2007110805 Minefield/3.0b2pre

Cannot drag & drop Russian (non-acsii?) text to the search and location bar 

Reproducible: Always

Steps to Reproduce:
Drag & drop "история" ("history" in Russian) to the search bar
Actual Results:  
Google search page for "история"

Expected Results:  
Google search page for "история"

I see the same problem with the location bar
> Cannot drag & drop Russian (non-acsii?) text to the search and location bar 

Bad wording. I can drag & drop, but search query encoding is broken
Version: unspecified → Trunk
This looks similar to bug 267364, though Neil tells me a different codepath is involved.
Component: Search → Drag and Drop
Product: Firefox → Core
QA Contact: search → drag-drop
Works fine in Fx 2.0.0.9
Given that it used to work OK, do you think you could go through "trunk" builds at http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/ and find a regression range?
Keywords: qawanted
Works in 2007-09-27-05-trunk
Fails in 2007-09-28-04-trunk

Bug #292607 maybe?
Sure looks like it.
Status: UNCONFIRMED → NEW
Depends on: 292607
Ever confirmed: true
Keywords: qawantedregression
Blocks: 292607
No longer depends on: 292607
Flags: blocking1.9?
Neil, what's going on here?
nsCopySupport :: HTMLCopy doesn't use any serialisation flags (don't ask me how or if it works with links). However for whatever reason nsTransferableFactory :: SerializeNodeOrSelection is still using absolute links and encoded entities. Unfortunately the HTML format converter can't cope with entities.
Flags: blocking1.9? → blocking1.9+
Attached patch Proposed patch (obsolete) — Splinter Review
I tried twiddling the bits in the debugger and it works without any flags.
I can now also drag-n-drop into Word (which was broken before bug 292607).

I tested this with the preformatted space test case, a relative link (which became absolute when dropped into Word or Composer) and the Russian text.
Assignee: nobody → neil
Status: NEW → ASSIGNED
But the old code used these flags...  What's changed?
I don't know, but my 6 month old XPFE build won't drag Russian text into Word.
FYI: Also happens on OS X with FF3 + Prototheme. I selected and dragged the text from the comment above from the FF3 browser window to the search bar and has exactly the same results.
Priority: -- → P2
neil: (either one) can you take a look at this?
Flags: tracking1.9+
(In reply to comment #10)
> But the old code used these flags...  What's changed?
> 

The old code converted from DOM->HTML Source and DOM->Unicode. The current code converts from DOM->HTML Source and then HTML Source->Unicode.

However, the bug is caused because the DOM->HTML Source step (done by nsDocumentEncoder) converts the Cyrillic characters into entities like с, but the HTML Source->Unicode step (done by the html parser) doesn't understand these entities so just outputs them as plaintext.
Assignee: neil → enndeakin
Attachment #288297 - Attachment is obsolete: true
Attachment #306576 - Flags: superreview?
Attachment #306576 - Flags: review?
Attachment #306576 - Flags: superreview?(jst)
Attachment #306576 - Flags: superreview?
Attachment #306576 - Flags: review?(jst)
Attachment #306576 - Flags: review?
Attachment #306576 - Flags: superreview?(jst)
Attachment #306576 - Flags: superreview+
Attachment #306576 - Flags: review?(jst)
Attachment #306576 - Flags: review+
> Neil Deakin:
> Created an attachment (id=306576) [details]
> fix by just translating the html entities

Thank you!
It's work for me.
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Neil, may we hope to see this patch in the Mozilla Firefox release?
I have install FF3-beta4, but, to my great surprise, this problem was don't fixed... :( Is it forgotten?

---
Sorry for my bad English...
Beta 4 predates this patch being checked in.
verified fixed using the steps to reproduce from comment #0 and Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9pre) Gecko/2008042705 Minefield/3.0pre ID:2008042705 - works as expected now.

--> Verified fixed
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.