PDF Previewer changes Font on selected text when Browser loses focus

RESOLVED DUPLICATE of bug 815170

Status

()

Firefox
PDF Viewer
RESOLVED DUPLICATE of bug 815170
4 years ago
4 years ago

People

(Reporter: Rob, Unassigned)

Tracking

Trunk
x86
Windows XP
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

4 years ago
I am using FF Nightly 29.0a1 (2014-01-14). When I visit http://www.cscamm.umd.edu/programs/ocq05/adams/adams_ocq05.pdf, and 'left-click select text' on the first Page, then alt-Tab away (lose focus), the Font changes.

The change could be described as Superscripting; without the associated reduction in Font size that often (always?) accompanies such an operation.


I suggest this _must_ be incorrect behaviour because why would we want this to happen and why does the Browser perform an additional operation (of this nature, changing a Font) after it loses focus; generally (always?) losing Focus means you are finished your turn.
Mozilla/5.0 (Windows NT 5.1; rv:29.0) Gecko/20100101 Firefox/29.0
Reproduced on latest Nightly (20140114030236).
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 2

4 years ago
In my spare time I have been looking and testing more. I can not find one PDF from any Site unaffected by this Bug. Surprising it was not noticed sooner. I imagine this Bug was present for some time; please do not ask me for a regression (hehe).
(Reporter)

Comment 3

4 years ago
An additional point that the Bug was implemented incorrectly. If the selected Text is italicized then when the Browser loses focus the italicization of the Font is also lost, and the Text is simply 'superscripted' (without the associated decrease in font size that "superscripts" normally have).

That suggests to me that unless one were to make a specific function call to do that one unlikely thing then it would be unlikely to occur; and surely we do not make such a call (I presume without looking at the Source). 

Thus, it is my premise that this is a pointer/memory error. Possibly a Table that holds various 'Font Properties' is not properly defined (and some 'default' is thus relied upon), and the correct 'state' is not being made available after the 'context switch'. (IE: I speculate that looking at the Code near where we change focus will not lead us to the source of this problem).

If this is a Pointer/Memory issue (Code elsewhere is causing the Bug here) should the "Importance" go above "Normal"; I'll leave that to Triage.

I still find this occurs at every Site with a PDF (that has selectable Text).
(Reporter)

Comment 4

4 years ago
With this PDF (which is partly English, and mostly Korean) http://www.rfdh.com/ez/system/db/pds_tn/upload/274/9901.pdf if you select the English text the Font will change to what appears to be a different Font (it could be another 'Glyph Set' within the same Font). This is in addition to the previously reported behaviour.

Updated

4 years ago
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 815170
(Reporter)

Comment 6

4 years ago
(In reply to Brendan Dahl [:bdahl] from comment #5)
> 
> *** This bug has been marked as a duplicate of bug 815170 ***

I disagree that my BR is a duplicate.

I have reviewed Bug 815170 and the other Bugs that were marked Dupes of 815170.

Bug 815170 is about highlighting and upon losing focus one can not read the Text, (IE: it becomes "all grey").

Bug 960070 (mine) is about selected text superscripting itself when focus is lost and remaining visible (IE: it is not "all grey"). Further, my Comment 4 also serves to differentiate the two Reports.

If someone else knows better (both Bugs DO involved the same Code) it is OK to set the Staus back as it was, but it seems quite a stretch to suggest that the symptoms described are in any manner similar.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
(Reporter)

Comment 7

4 years ago
The PDF @ https://s3.amazonaws.com/Heartweb/Tutorial_Sample_Instructions.pdf produces a somewhat opposite result from most other PDFs (which demonstrate the Bug in Comment 1).

The above URL's PDF will SUBscript the Text, whereas the URL reported in Comment 0 SUPERscripted the Font. Most PDF do NOT fall into this category, it seems a new manifestation of the same Bug.


That permitted me to notice another difference. 

1A. The SUPERscripted PDFs will take "Normal" (not "Bold") Text, make it Bold and does not SEEM to alter the Font's size.

1B. The SUPERscripted PDFs will take "Bold" Text, make it "Normal" and (it looks like it) slightly reduces the Font size.

2A. The SUBscripted PDFs will take "Normal" (not "Bold") Text, make it Bold and does not appear to alter the Font's size. (Similar to 1A, for "Font Size" alteration).

2B. The SUBscripted PDFs will take "Bold" Text, make it "Normal" and (it looks like it) does NOT alter the Font size. (Different from 1B, for "Font Size" alteration).

Also, I noticed that any italicization is being removed from the Fonts, the Fonts are being Sub/Superscripted with the "Normal" Font.
The affect is slightly different, but it is the same bug.
Status: REOPENED → RESOLVED
Last Resolved: 4 years ago4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 815170
You need to log in before you can comment on or make changes to this bug.