Closed Bug 479107 Opened 13 years ago Closed 12 years ago

non-ASCII characters aren't decoded correctly after customize toolbar

Categories

(SeaMonkey :: Location Bar, defect)

x86
Windows Vista
defect
Not set
normal

Tracking

(blocking-seamonkey2.1 needed)

RESOLVED FIXED
Tracking Status
blocking-seamonkey2.1 --- needed

People

(Reporter: JasnaPaka, Assigned: philip.chee)

References

()

Details

Attachments

(3 files, 3 obsolete files)

Mozilla/5.0 (Windows; U; Windows NT 6.0; cs; rv:1.9.1b3pre) Gecko/20090218

Steps to reproduce:
1) In browser set toolbar icons to small size.
2) Visit URL: http://cs.wikipedia.org/wiki/Vla%C5%A1sk%C3%BD_o%C5%99ech
3) Restore toolbar to default.

Now you can see URL which isn't decoded correctly.
I can confirm it with  Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090219 SeaMonkey/2.0b1pre.

Change shall be made by the item "Customize... => Use Small Icons"
Status: UNCONFIRMED → NEW
Ever confirmed: true
Depends on: 425480
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20090221 NOT Firefox/2.0.0.20 SeaMonkey/2.0a3pre ID:20090221175141

I can't reproduce this on Fedora Core 10.
I see the problem - we forgot to update BrowserCustomizeToolboxDone()...
I even have a XXXRatty placeholder comment there.
blocking-seamonkey2.1: --- → ?
I wouldn't push out any specific release for this, as nothing is really broken, but we'll need a fix at some time in this cycle.
blocking-seamonkey2.1: ? → needed
I can't see any difference. Can someone comment on the actual string seen vs the expected string.
(In reply to comment #6)
> I can't see any difference. Can someone comment on the actual string seen vs
> the expected string.

See attachments.
Attached patch Patch v1.0 Update URLBar. (obsolete) — Splinter Review
> See attachments.

Thanks I see it now.
Assignee: nobody → philip.chee
Status: NEW → ASSIGNED
Attachment #448040 - Flags: review?(neil)
Comment on attachment 448040 [details] [diff] [review]
Patch v1.0 Update URLBar.

>   // Update the urlbar
>-  var value = gBrowser.userTypedValue;
...
>-  gURLBar.value = value;
>+  URLBarSetURI();

I'm not sure what's going on with SM's URLBarSetURI implementation. Unlike Firefox's, it doesn't seem to read userTypedValue (but resets it even).
(In reply to comment #11)
> (From update of attachment 448040 [details] [diff] [review])
> >   // Update the urlbar
> >-  var value = gBrowser.userTypedValue;
> ...
> >-  gURLBar.value = value;
> >+  URLBarSetURI();
> I'm not sure what's going on with SM's URLBarSetURI implementation. Unlike
> Firefox's, it doesn't seem to read userTypedValue (but resets it even).
Our version expects the caller to deal with reading userTypedValue (and assumes that it was or it needs to be reset).
Comment on attachment 448040 [details] [diff] [review]
Patch v1.0 Update URLBar.

As per comment 11.
Attachment #448040 - Flags: review?(neil) → review-
>> I'm not sure what's going on with SM's URLBarSetURI implementation. Unlike
>> Firefox's, it doesn't seem to read userTypedValue (but resets it even).
> Our version expects the caller to deal with reading userTypedValue (and assumes
> that it was or it needs to be reset).

I hope I've understood Comment 11 correctly.
Attachment #448040 - Attachment is obsolete: true
Attachment #448196 - Flags: review?(neil)
You can test the outcome quite easily: Type into the location bar, customize toolbars, cancel, observe whether the typed value is restored.
Comment on attachment 448196 [details] [diff] [review]
Patch v1.1 Restore userTypedValue.

Don't you actually need to restore the user typed value (if any) to the URLbar itself?
Attachment #448196 - Flags: review?(neil)
> Don't you actually need to restore the user typed value (if any) to the URLbar
> itself?
Ah, finally understood what userTypedValue is used for.
Attachment #448196 - Attachment is obsolete: true
Attachment #448273 - Flags: review?(neil)
Comment on attachment 448273 [details] [diff] [review]
Patch v1.2 Restore to gURLBar.value as well.

Well, that's functional, but when you do have a user typed value then you're making work for yourself by setting the URLbar twice and having to restore userTypedValue too.
> Well, that's functional, but when you do have a user typed value then you're
> making work for yourself by setting the URLbar twice and having to restore
> userTypedValue too.
Sorry about that. Fixed.
Attachment #448273 - Attachment is obsolete: true
Attachment #448329 - Flags: review?(neil)
Attachment #448273 - Flags: review?(neil)
Attachment #448329 - Flags: review?(neil) → review+
Blocks: 569318
Pushed to comm-central:
http://hg.mozilla.org/comm-central/rev/27777aeb1642
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.