Closed Bug 722323 Opened 10 years ago Closed 7 years ago

It's difficult to type data URI when inline autocomplete suggests very long data URI

Categories

(Firefox :: Address Bar, defect)

x86_64
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: masayuki, Assigned: mak)

References

Details

(Keywords: regression, Whiteboard: [inline-autocomplete:normal])

When I make a simple testcase by data URI in the locationbar, it's difficult to type characters by inline autocomplete.

Steps to reproduce:

1. type (or paste) a long data URI in location bar and load it, e.g.,

> data:text/html,<input%20id="i"><label><input%20type="checkbox"%20id="check">%20call%20preventDefault()%20of%20compositionstart</label><p%20id="p"></p><script%20type="text/javascript">var%20input%20=%20document.getElementById("i");%20var%20p%20=%20document.getElementById("p");%20function%20handler(e)%20{%20if%20(document.getElementById("check").checked%20&&%20e.type%20==%20"compositionstart")%20{%20e.preventDefault();%20}%20p.innerHTML%20=%20e.type%20+%20":%20data=\""%20+%20e.data%20+%20"\",%20locale=\""%20+%20e.locale%20+%20"\"<br>"%20+%20p.innerHTML;%20}%20function%20handler2(e)%20{%20p.innerHTML%20=%20e.type%20+%20":%20data=\""%20+%20e.data%20+%20"\",%20locale=\""%20+%20e.locale%20+%20",%20inputMethod="%20+%20e.inputMethod%20+"\"<br>"%20+%20p.innerHTML;%20}%20function%20keyname(event)%20{%20for%20(var%20s%20in%20event)%20{%20if%20(s.match(/^DOM_VK_/)%20&&%20event[s]%20==%20event.keyCode)%20{%20return%20s;%20}%20}%20return%20"0x"%20+%20event.keyCode.toString(16);%20}%20function%20keyhandler(event)%20{%20var%20p%20=%20document.getElementById("p");%20p.innerHTML%20=%20event.type%20+%20"%20keyCode="%20+%20keyname(event)%20+%20",%20charCode="%20+%20event.charCode%20+%20"%20(0x"%20+%20event.charCode.toString(16)%20+%20"),%20shift="%20+%20event.shiftKey%20+%20",ctrl="%20+%20event.ctrlKey%20+%20",%20alt="%20+%20event.altKey%20+%20",%20meta="%20+%20event.metaKey%20+%20"<BR>"%20+%20p.innerHTML;%20}%20input.addEventListener("compositionstart",%20handler,%20false);%20input.addEventListener("compositionupdate",%20handler,%20false);%20input.addEventListener("compositionend",%20handler,%20false);%20input.addEventListener("textinput",%20handler2,%20false);%20input.addEventListener("keydown",%20keyhandler,%20false);%20input.addEventListener("keypress",%20keyhandler,%20false);%20input.addEventListener("keyup",%20keyhandler,%20false);</script>

2. type "data:text/html,<input" in the location bar.

Then, the first URI is suggested by inline autocomplete, but the editor is scrolled to the end of the URI. I.e., I cannot see the insertion point when I'm typing.

So, I think that the inline autocomplete should be disabled when user types data URI.
sounds like a good idea, actually we may even crop results, in the sense that if a result is over a certain number of chars we may just not suggest it. Since not just data uris may be problematic.
Whiteboard: [inline-autocomplete:normal]
Assignee: nobody → mak77
Status: NEW → ASSIGNED
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
after doing the first changes, I find out the char limit solution, while easy to do is quite hackish. it should probably be settable for each input, thus I added a completeDefaultIndexMaxLength property, but it's really hard to guess a good value for flex fields and saying in the idl "if we are over this limit we won't return a suggestion" sounds a bit like breaking the promise.
I wonder if would not be better to try to think a solution in the frontend that just keeps the typed text visible instead of scrolling the edit field to the right.
Even if it's difficult, I think that the selection start position should be visible because it's the place where the user watches.
Wasn't this fixed already?
not that I'm aware of, though it is less hitting cause now we only suggest typed results and it's hard to type a data uri (though c/p may still hit here I think)
The hang happens not only in data uri but also in ordinary long uri
See https://bugzilla.mozilla.org/show_bug.cgi?id=995156
See Also: → 995156
Blocks: 995156
No longer blocks: 995156
I don't see this bug in these days.
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.