Closed Bug 174197 Opened 22 years ago Closed 21 years ago

font error when link bookmarked

Categories

(Core :: Internationalization, defect)

Product:
Core
Component:
Internationalization
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
VERIFIED WORKSFORME
Milestone:
mozilla1.4beta

People

(Reporter: enpontus, Assigned: smontagu)

References

Details

(Keywords: intl, testcase, Whiteboard: [adt2] [fixed and verified on 1.3 branch] fixed1.3)

Attachments

(5 files, 1 obsolete file)

Testcase from dupe.
98 bytes, text/html
Details
Screenshot
9.56 KB, image/gif
Details
Patch v.2
1014 bytes, patch
Details | Diff | Splinter Review
Patch for 1.3 branch
852 bytes, patch
bryner
: review+
blizzard
: superreview+
dbaron
: approval1.3+
Details | Diff | Splinter Review
Patch for trunk
887 bytes, patch
janv
: review+
jag+mozilla
: superreview+
Details | Diff | Splinter Review 
the character encoding swithces when site icon dragged onto personal bar for
e.g. european fonts

Recipy:

1. Go to http://www.alternativet.nu
2. Check that the swedish characters å,ä,ö exists in the text
3. Bookmark the page as described
4. Reload
5. Swedish characters gone

i have seen this at more sites but i cannot recall their names for the moment
I'm confirming this bug for now. This is what appear to be happening.


1. At first load the character coding  defaults to Western ISO-8859-1.
2. The user bookmarks and reloads the page
3. Now the character encoding defaults to UTF-8, making the special characters 
appear as ? signs

Additional information:

* Manually switching the character coding back to Western ISO-8859-1 works, but 
it is lost on the next reload (se below)

* It seems to be more connected with "Reload" than bookmarking. After having 
played a little with it:

  - Reloading seems to switch between the two encoding, thus having every 
second load be in UTF-8 and the rest in Western ISO, so basicly the site works 
half the time.
  - Loading new pages by following links does not switch encoding.

*  my tests are done with: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; 
rv:1.2b) Gecko/20021007
Assignee: asa → harishd
Status: UNCONFIRMED → NEW
Component: Browser-General → Parser
Ever confirmed: true
QA Contact: asa → moied
For me the enconding is windows-1252 (Mac OS 91. Build 2002100911). I have set
Auto detect Universal. 
It works fine.
I don't see any language meta tags.

At load, I have also the folowing JS Error:
Error: doc.layers has no properties
Source File: http://www.alternativet.nu/dhtmllib.js
Line: 373

->Internationalization
Assignee: harishd → yokoyama
Component: Parser → Internationalization
QA Contact: moied → ruixu
Keywords: intl
QA Contact: ruixu → ylong
This happens when dragging and dropping from the URL bar to the Personal
toolbar, because navigatorDD.js passes to the bookmark service the charset of
the document where the drag originates, which in this case is a XUL document in
the chrome with charset UTF-8.

http://lxr.mozilla.org/seamonkey/source/xpfe/browser/resources/content/navigatorDD.js#344
nhotta: can we do anything about this?
*** Bug 177270 has been marked as a duplicate of this bug. ***
Can reproduce it on windows latest trunk build, change platform to All.

I think it's a bad bug, nominate as nsbeta1.
Keywords: nsbeta1
OS: Linux → All
Hardware: PC → All
Raising severity to major per duplicate bug.

I assume this is a regression.  Any ideas when it started?  It seems like an
ugly bug to have in 1.2.
Severity: normal → major
the bug has been present for Linux for very long (i would _guess_ pre 1.0)
i simply didn't  find the reason for the behaviour the first time
Attached file Testcase from dupe. — 
Steps to reproduce:
 1. Load testcase.
 2. Drag the icon in the URL bar to the personal toolbar.
 3. Hit the back button.
 4. Click on the icon in the personal toolbar just created.
Keywords: testcase
This seems to be a PC only bug. It doesn't happen on Mac OS X, and comment 2
suggests it doesn't happen in legacy Mac OS 9 either.

The TestCase works fine On Mac OS 9.1 Build 2002110808.
No problems
Blocks: 157673
Keywords: mozilla1.3
I can reproduce this on window 01142003 build. It looks very bad. It show wrong
and right every other times.


i18n triage team: nsbeta1+/adt2
Assignee: yokoyama → ftang
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [adt2]
assign
Status: NEW → ASSIGNED
I update my local build and I can no longer reproduce this problem. I think the
problem is fixed. mark it as wfm.
please reopen if you can still reproduce this.
Did you do the steps in comment 10? I still see the bug on Windows 2000, build
2003021208.
Attached image Screenshot — 
Only thing that changed is that before i got the ?, now i get this black
squares instead.
Flags: blocking1.3? → blocking1.3+
both testcases work for me with today's linux build on RH8 but do not work on
today's windows build on winXP (sp1) or Mac OS X (10.2.3). The titlebar and the
content from the testcase in comment 10 are both broken. 
Simon: Can you take a look at this one? Its blocking Moz 1.3. Thanks!

reassigning to smontagu.
Assignee: ftang → smontagu
Status: ASSIGNED → NEW
(I think I was probably being a bit overzealous when I marked this as a blocker,
although a fix would be nice.  I don't think we'd really hold for it if it came
down to that.)
Attached patch Patch (obsolete) — — Splinter Review 
This patch is based on the idea in comment 4 and prevents the bug (using the
test procedure in comment 10).

However, I smell some bogosity:

(a) When I debug, aDragSession.sourceDocument always seems to be null except
when the drag originates in chrome.
(b) Does the current algorithm make sense? Why is the charset of the linking
document considered to have anything to do with the linked document?
The only case I can see where you might want to remember the encoding is where
the drag originates from the URL bar, but in that case you'd want to remember
the encoding of the document being displayed, not the encoding of the XUL document.

If we can't detect that case correctly, then why not just make it null all the time?
I wonder if we can search for the charset in global history, as we currently do
for the title at
http://lxr.mozilla.org/seamonkey/source/xpfe/browser/resources/content/navigatorDD.js#358
Attached patch Patch v.2 — — Splinter Review 
This way of testing whether we are bookmarking the current document seems to
work...
Attachment #115432 - Attachment is obsolete: true
... but perhaps it would be safer just to go with setting the charset to null
on the branch, and try to find out how to set it correctly for 1.4.
Attachment #115455 - Flags: superreview?(blizzard)
Attachment #115455 - Flags: review?(bryner)
Comment on attachment 115455 [details] [diff] [review]
Patch for 1.3 branch

sr=blizzard
Attachment #115455 - Flags: superreview?(blizzard) → superreview+
Attachment #115455 - Flags: review?(bryner) → review+
Comment on attachment 115455 [details] [diff] [review]
Patch for 1.3 branch

Requesting approval for 1.3 final.

As far as I can tell (see comment 22), the current code will never produce a
correct result except by coincidence and will often produce an incorrect result
as in this bug. This branch-only patch prevents the incorrect result by never
setting a charset in a bookmark created by dragging a link. I will leave the
bug open for investigating ways to set a correct charset at least some of the
time, but I don't want to hold up the branch for that.
Attachment #115455 - Flags: approval1.3?
The fix is checked in to the 1.3 branch. Since there is no fixed1.3 keyword and
this is a blocker, should I close the bug so it disappears from the radar, and
open a new bug for the trunk?
Verified fixed on 1.3 mozilla branch build, but still exists in 02-27 trunk build.
Whiteboard: [adt2] → [adt2] [fixed and verified on 1.3 branch]
Whiteboard: [adt2] [fixed and verified on 1.3 branch] → [adt2] [fixed and verified on 1.3 branch] fixed1.3
Any progress on fixing this for the trunk?
Flags: blocking1.4a?
I'd like to extend attachment 115450 [details] [diff] [review] as described in comment 24 and then seek
reviews for the trunk, but I need to do some research first on how to do that,
or whether it is even possible.
No, global history doesn't seem to know anything about charsets. My current
design for a fix is as follows:

If the URI being bookmarked is the current document, use the current charset.
Otherwise, if there is an existing bookmark for the URI, copy its charset.
Otherwise make the charset null.

Targetting to 1.4b, to keep it behind stuff that I want to get into 1.4a.
Target Milestone: --- → mozilla1.4beta
Flags: blocking1.4a? → blocking1.4a-
I dont know if it matters, but this was not completely fixed in Mozilla 1.3. I
still sometimes get the � instead of swedish characthers. Though the testcase in
this bug works fine.
Attached patch Patch for trunk — — Splinter Review 
It seems that in the new bookmarks world, no extra code is required to get the
charset from the current (focused) document, so this patch should be
sufficient.
Attachment #121216 - Flags: superreview?(jaggernaut)
Attachment #121216 - Flags: review?(varga)
Attachment #121216 - Flags: review?(varga) → review+
Comment on attachment 121216 [details] [diff] [review]
Patch for trunk

sr=jag
Attachment #121216 - Flags: superreview?(jaggernaut) → superreview+
Patch checked in.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Verified fixed on 04-22 trunk build.
Status: RESOLVED → VERIFIED
Flags: blocking1.4b?
Seing this again with build 2003051504, Windows 2000:

To reproduce do this:
1. Save "Testcase from dupe." locally. 
2. Load the page, drag the link to the toolbar
3. Press the link, you will see the error

Also, reloading the page fixes the problem, to reproduce, remove the link from
the toolbar, restart mozilla and follow the steps above.

I can attach a screenshot if necessary to show that this happends with a new build.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
I can reproduce the problem by following the steps in previous comment on 05-16
trunk build / WinXP and Win2000:
When I load the bookmark of the test case in personal toolbar from saved LOCAL file.

However, when I bookmark the test case directorily from attachment, then I won't
see it.  The current problem is a little different from the orginal bug, because
it was seen even load the bookmark that directory drag from html page before. 
Maybe we should open a new bug for the current problem and close this one. 
This is not only when the file is saved locally, I have a swedish site 
bookmarked and I see this very often. Maybe because its cached?
If you created the bookmark before this was fixed, I think you will go on seeing
the problem. Try deleting the bookmark and creating a new one.
Yes, you are right, 
Should I open a new bug for comment 39 or leave this one reopened?
I think comment 39 should be filed as a new bug. Marking this WORKSFORME.
Status: REOPENED → RESOLVED
Closed: 21 years ago → 21 years ago
Resolution: --- → WORKSFORME
Mark as verified for this bug.  Please open a new bug for the problem in comment
39 with clear steps, thanks!
Status: RESOLVED → VERIFIED
Bug 207338 was filed for was is mentioned in comment 39
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: