Closed Bug 903475 Opened 11 years ago Closed 11 years ago

hang collecting lookups within OT::LigatureSubstFormat1::collect_glyphs

Categories

(Core :: Graphics: Text, defect)

23 Branch
defect
Not set
critical

Tracking

()

VERIFIED FIXED
mozilla26
Tracking Status
firefox23 - wontfix
firefox24 + verified
firefox25 + verified
firefox26 + verified

People

(Reporter: stepand76, Assigned: jtd)

References

()

Details

(Keywords: hang, regression)

Attachments

(7 files)

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20100101 Firefox/22.0 (Beta/Release)
Build ID: 20130618035212

Steps to reproduce:

Just navigated to folowing page: http://www.flotrack.org/coverage/249744-Workout-Wednesday-Season-7/video/684139-WOW-Rupp-in-the-Weightroom


Actual results:

It freezes while loading the page.


Expected results:

Load the page.
Firefox 22 loads the page correctly, but Firefox 23 and 24 (beta) doesn't.
Could you try with a clean profile, please:
https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles
Flags: needinfo?(stepand76)
Severity: normal → critical
Keywords: hang
Summary: Firefox 23 freezes in safe mode → [Flash?] Firefox 23 freezes in safe mode
(In reply to Loic from comment #2)
> Could you try with a clean profile, please:
> https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-
> firefox-profiles

Just tried with the new profile. It is the same. What another should I try?
Flags: needinfo?(stepand76)
Tried to reinstall flash but no change.
1) Are you running the latest version of Flash (11.8.800.94)?

2) Could you test with HWA disabled in Flash Player.
http://www.macromedia.com/support/documentation/en/flashplayer/help/help01.html

3) In addition, make a try with the "protected mode" disabled in Flash.
http://forums.adobe.com/thread/1018071?tstart=0 (chapter "last resort", run Notepad as admin to open mms.cfg)

NB: reset each change if that doesn't fix anything.
Flags: needinfo?(stepand76)
(In reply to Loic from comment #5)
> 1) Are you running the latest version of Flash (11.8.800.94)?
> 
> 2) Could you test with HWA disabled in Flash Player.
> http://www.macromedia.com/support/documentation/en/flashplayer/help/help01.
> html
> 
> 3) In addition, make a try with the "protected mode" disabled in Flash.
> http://forums.adobe.com/thread/1018071?tstart=0 (chapter "last resort", run
> Notepad as admin to open mms.cfg)
> 
> NB: reset each change if that doesn't fix anything.

1) Yes.
2) Doesn't help.
3) Doesn't help.
Flags: needinfo?(stepand76)
IMHO it is not related to flash. Today it hangs on our product webpage (www.reliance-scada.com). There is no flash.
This website WFM.
Are you using a proxy or something like that?
(In reply to Loic from comment #8)
> This website WFM.
> Are you using a proxy or something like that?

What is WFM?
No. I do not use a proxy.
Works For Me, the website reliance-scada.com doesn't hange/freeze Firefox.
I found another no-flash page which hangs my Firefox 23. http://npa.cz/
What next can I try?
I've tried it on three computers - everytime with FF 22, FF 23 and FF 24b2 - every time with used profile, safemode, new profile - all the mentioned websites are working a no freeze occurred.
The bug I reported here I can reproduce only on my desktop computer and only with FF 23 and newer. On the other one (my laptop) it works.
Can you reproduce it in Windows Safe mode? Probably there could be some issue with your GPU drivers or system in general - try to disable HW acceleration in Firefox as well as in Flash itself or reinstall your computer. Maybe restoring to it's previous state may help too.
I started my Windows in safe mode, FF 23 in safe mode, used clean profile, disabled HW acceleration in Firefox and in Flash, but it still freezes. I will stay with FF 22 where I never had a problem...
In your computer where Firefox freezes, could you install the tool mozregression (see http://harthur.github.io/mozregression/ for details) to find a possible regression range.

FF23 builds started in April 2013 (mozregression --good=2013-04-01).

Paste here the output of the console.
Nice tool BTW. Here is the output:

Downloading nightly from 2013-06-07
Installing nightly
Starting nightly
Was this nightly good, bad, or broken? (type 'good', 'bad', 'skip', 'retry', or
'exit' and press Enter): bad
Downloading nightly from 2013-05-04
Installing nightly
Starting nightly
Was this nightly good, bad, or broken? (type 'good', 'bad', 'skip', 'retry', or
'exit' and press Enter): bad
Downloading nightly from 2013-04-17
Installing nightly
Starting nightly
Was this nightly good, bad, or broken? (type 'good', 'bad', 'skip', 'retry', or
'exit' and press Enter): bad
Downloading nightly from 2013-04-09
Installing nightly
Starting nightly
Was this nightly good, bad, or broken? (type 'good', 'bad', 'skip', 'retry', or
'exit' and press Enter): good
Downloading nightly from 2013-04-13
Installing nightly
Starting nightly
Was this nightly good, bad, or broken? (type 'good', 'bad', 'skip', 'retry', or
'exit' and press Enter): bad
Downloading nightly from 2013-04-11
Installing nightly
Starting nightly
Was this nightly good, bad, or broken? (type 'good', 'bad', 'skip', 'retry', or
'exit' and press Enter): good
Downloading nightly from 2013-04-12
Installing nightly
Starting nightly
Was this nightly good, bad, or broken? (type 'good', 'bad', 'skip', 'retry', or
'exit' and press Enter): bad


Last good nightly: 2013-04-11
First bad nightly: 2013-04-12

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2949e808ed33&tochan
ge=7b8ed29c6bc0

do you want to bisect further by fetching the repository and building? (y or n)
y
Building changesets:
hg not installed on this system.

C:\mozilla-build\python\Scripts>
> Pushlog:
> http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2949e808ed33&tochange=7b8ed29c6bc0

This changeset does not reflect anything landing on mozilla-central so there's nothing we can action there. If you yourself can only reproduce this on *one* of your computers it's possible there is something on that system causing the problem. Have you tried using virus and malware scanners, clearing your cache and temporary files, defragging your system, etc?
(In reply to Loic from comment #19)
> The pushlog is:
> http://hg.mozilla.org/mozilla-central/
> pushloghtml?fromchange=2949e808ed33&tochange=7b8ed29c6bc0
> 
> This link works, no?

Yes it works, but the changes listed there are not landings to mozilla-central. They are changes being merged *from* mozilla-central *to* inbound and fx-team. In short, there are no changes being landed on mozilla-central in this pushlog and therefore no possibility of identifying a regressive patch using this pushlog.
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #20)
> (In reply to Loic from comment #19)
> > The pushlog is:
> > http://hg.mozilla.org/mozilla-central/
> > pushloghtml?fromchange=2949e808ed33&tochange=7b8ed29c6bc0
> > 
> > This link works, no?
> 
> Yes it works, but the changes listed there are not landings to
> mozilla-central. They are changes being merged *from* mozilla-central *to*
> inbound and fx-team. In short, there are no changes being landed on
> mozilla-central in this pushlog and therefore no possibility of identifying
> a regressive patch using this pushlog.

No, Actually they merged from (inbound/fx) to (m-c).
(In reply to Alice0775 White from comment #21)
> No, Actually they merged from (inbound/fx) to (m-c).

That's not what the comment says, "Merge m-c to inbound". Maybe I'm misunderstanding the pushlog. Regardless this pushlog needs further testing to prove this is a bug in Firefox. I'm still concerned that this only seems to happen on *one* of the reporter's computers. This points to a problem with that PC or some combination of hardware, software, and Firefox.

Our engineering team will need an internally reproducible test case before they can even begin investigating a fix.
> Our engineering team will need an internally reproducible test case before
> they can even begin investigating a fix.

As a developer I absolutely understand what do you mean. I think there is something wrong with my computer, *BUT* strange is that FF22 working like a charm on the same computer, with the same profile. So there must be something what changed meanwhile. What it can be? I'm ready to help you with detecting the issue.
Could you make a try with HWA disabled in FF.
https://support.mozilla.org/en-US/kb/forum-response-disable-hardware-acceleration
(In reply to Loic from comment #24)
> Could you make a try with HWA disabled in FF.
> https://support.mozilla.org/en-US/kb/forum-response-disable-hardware-
> acceleration

See my comment #15.
I found that HTML code bellow hangs FF23 on my computer. If I remove the iframe then it works. Maybe it can help you with tracking the bug.



<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
        "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
    <title></title>
</head>
<body>

<!-- BLUEBOARD SHOUTBOARD -->
	<iframe frameborder="0" scrolling="no" width="135" height="420" src="http://miniaplikace.blueboard.cz/shoutboard.php?hid=9ba94nff1kod9mfjb6puk1x8r5nk3o">
	<a href="http://miniaplikace.blueboard.cz/shoutboard.php?hid=9ba94nff1kod9mfjb6puk1x8r5nk3o">ShoutBoard od BlueBoard.cz</a>
	</iframe>
	<!-- BLUEBOARD SHOUTBOARD KONEC -->

</body>
</html>
I've attached your testcase to this bug. Unfortunately it does not reproduce a hang for me with Firefox 23.0.1 on Windows 7 or Windows 8 with Flash 11.8.800.94. Is anyone else able to reproduce a hang?
No, everything works fine for me.
I just used Process Monitor to capture activity of firefox.exe. You can compare FF22 and FF23. It only shows the testcase page from local disc.
Benjamin, could you have a look at the ProcessMonitor logs attached to this bug and tell what's happening or assign this to someone who might know? Reproduction of this bug has elluded most of us so far.
Flags: needinfo?(benjamin)
The process monitor logs are not useful for diagnosing this. However, I do have a tool which will kill a hung Firefox in a way that should trigger the crash reporter: before hanging, please download http://benjamin.smedbergs.us/crashfirefox.exe and after you've hung, please run that program. It should kill Firefox and show the crash reporter. Once you submit the crash report, use about:crashes to get the crash report ID and paste it in this bug.
Flags: needinfo?(benjamin) → needinfo?(stepand76)
I'm using OS X 10.6.8 on a Core 2 Duo iMac and I think I have the same problem, but not on the same pages.

Firefox hangs if I try to load the gmail login page, or https://developer.mozilla.org/

To be sure that it is the same bug, I tested with nightly builds 2013-04-11 and 2013-04-12 and the bug only occurs at 2013-04-12.
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #33)
> The process monitor logs are not useful for diagnosing this. However, I do
> have a tool which will kill a hung Firefox in a way that should trigger the
> crash reporter: before hanging, please download
> http://benjamin.smedbergs.us/crashfirefox.exe and after you've hung, please
> run that program. It should kill Firefox and show the crash reporter. Once
> you submit the crash report, use about:crashes to get the crash report ID
> and paste it in this bug.

https://crash-stats.mozilla.com/report/index/c35e24f2-72f3-4deb-adc5-4f7102130828
Flags: needinfo?(stepand76)
This report indicates we're running OT::LigatureSubstFormat1::collect_glyphs(OT::hb_collect_glyphs_context_t *).

How many fonts do you have installed on the system? Are you willing to paste a list of all the fonts you currently have? It's possible that a particular font is triggering this behavior: I wonder if we have tools which can help figure out which one. jfkthame, any thoughts about next steps?
Component: Untriaged → Graphics: Text
Flags: needinfo?(jfkthame)
Product: Firefox → Core
Summary: [Flash?] Firefox 23 freezes in safe mode → Firefox 23 hangs in font code (even in safe mode)
This is caused by bug 761442, which added a check of GSUB/GPOS lookups in fonts.

Enabling textrun logging may help here:

1. Set the environment vars below:

  NSPR_LOG_MODULES=textrun:5,fontlist:5
  NSPR_LOG_FILE=c:\temp\textrun.log

2. Run Firefox and load the page that causes the hang

The logfile should give you clues about the text and fonts being used on the page that resulted in the hang.  It will also list the fonts on the system.
Blocks: 761442
Assignee: nobody → jdaggett
Summary: Firefox 23 hangs in font code (even in safe mode) → hang collecting lookups within OT::LigatureSubstFormat1::collect_glyphs
Could I ask the folks who are experiencing this to try and collect the textrun logfiles?

For OSX, open a Terminal window and use:

$ export NSPR_LOG_MODULES=textrun:5,fontlist:5
$ export NSPR_LOG_FILE=/Users/<username>/textrun.out
$ /Applications/Firefox.app/Contents/MacOS/firefox

Replace <username> with whatever your username is.  I suspect there's a bum font file that's tripping up the lookup handling code in harfbuzz but that's just a guess at this point.
Flags: needinfo?(stepand76)
Flags: needinfo?(ph.mongeau)
Flags: needinfo?(ph.mongeau)
(In reply to John Daggett (:jtd) from comment #38)
> Could I ask the folks who are experiencing this to try and collect the
> textrun logfiles?

Ok, I added two logfiles, one for the gmail login page, and the other one for https://developer.mozilla.org/
I think we have sufficient information in this bug to at least confirm there's a regression somewhere in Firefox 23. If a more precise regression window is needed please add the regressionwindow-wanted keyword.
Status: UNCONFIRMED → NEW
Ever confirmed: true
This wouldn't drive a chemspill of FF23 so not tracking there but will track for our upcoming channels - we're close to finishing up FF24 beta however, so please keep that in mind for the risk assessment on a fix nomination for uplift.
lsblakk, I agree that we don't have enough data to prompt a FF23 chemspill at present. But we should keep an eagle eye out in SUMO/feedback for reports of hangs on webpages, and prepared to revisit that decision if necessary; this isn't going to show up in crash-stats.

We might have some data on this via telemetry chromehang reports: vladan are you still monitoring those regularly for new items, or does this show up recently?
Flags: needinfo?(jfkthame) → needinfo?(vdjeric)
(In reply to ph.mongeau from comment #41)
> Ok, I added two logfiles, one for the gmail login page, and the other one
> for https://developer.mozilla.org/

Great, thanks.  Could you try one more thing?  On your system is a font family called "Terminus".  Could you disable that family and run Firefox again?  Just run FontBook and right click on the family name, then select disable.  I think this font might be the cause.
(In reply to John Daggett (:jtd) from comment #45)
> Great, thanks.  Could you try one more thing?  On your system is a font
> family called "Terminus".  Could you disable that family and run Firefox
> again?  Just run FontBook and right click on the family name, then select
> disable.  I think this font might be the cause.

Yep, that's it! It doesn't hang when I disable Terminus.
Terminus the bitmap font?

Humm, John / Jonathan, can you check the get_table() callback implementation passed to HarfBuzz on OS X?  Why do we think that font may have a GSUB table?
Philippe sent me the copy of Terminus that was causing the problem.  Looks pretty old and it does indeed have a GSUB table.

Steps to reproduce:

1. Download and install attached font
2. Click on URL

Result: infinite loop within harfbuzz lookup code:

#0  0x0000000104a3a1a6 in OT::LigatureSet::collect_glyphs (this=0x108729e80, c=0x7fff5fbf5158) at hb-ot-layout-gsub-table.hh:691
#1  0x0000000104a3a129 in OT::LigatureSubstFormat1::collect_glyphs (this=0x1243cfdac, c=0x7fff5fbf5158) at hb-ot-layout-gsub-table.hh:772
#2  0x0000000104a3a00d in OT::hb_collect_glyphs_context_t::dispatch<OT::LigatureSubstFormat1> (this=0x7fff5fbf5158, obj=@0x1243cfdac) at hb-ot-layout-gsubgpos-private.hh:151
#3  0x0000000104a39c54 in OT::LigatureSubst::dispatch<OT::hb_collect_glyphs_context_t> (this=0x1243cfdac, c=0x7fff5fbf5158) at hb-ot-layout-gsub-table.hh:868
#4  0x0000000104a3981a in OT::SubstLookupSubTable::dispatch<OT::hb_collect_glyphs_context_t> (this=0x1243cfdac, c=0x7fff5fbf5158, lookup_type=4) at hb-ot-layout-gsub-table.hh:1080
#5  0x0000000104a3968e in OT::SubstLookup::dispatch<OT::hb_collect_glyphs_context_t> (this=0x1243cfd54, c=0x7fff5fbf5158) at hb-ot-layout-gsub-table.hh:1302
#6  0x0000000104a11aef in OT::SubstLookup::collect_glyphs_lookup (this=0x1243cfd54, c=0x7fff5fbf5158) at hb-ot-layout-gsub-table.hh:1152
#7  0x0000000104a0cdf7 in hb_ot_layout_lookup_collect_glyphs (face=0x1282ffc40, table_tag=1196643650, lookup_index=0, glyphs_before=0x1284b4000, glyphs_input=0x1284b4000, glyphs_after=0x1284b4000, glyphs_output=0x1284b4000) at /builds/mozcentral/gfx/harfbuzz/src/hb-ot-layout.cc:616
Hmmm, should Coverage::Iter::more really be returning true for unknown
formats?  Given that next() will be a no-op?

    inline bool more (void) {
      switch (format) {
      case 1: return u.format1.more ();
      case 2: return u.format2.more ();
      default:return true;
      }
    }
Ugh.  Of course not.  Does that fix the issue?
Looks like something I fixed on July 30 in:

commit 48382e2f41499a91181bea0acc5792989d2485bb
(In reply to Behdad Esfahbod from comment #50)
> Ugh.  Of course not.  Does that fix the issue?

Yup. :P

What about sanitize, there are a couple instance where it returns 'true' for unknown formats:

  inline bool sanitize (hb_sanitize_context_t *c) {
    TRACE_SANITIZE (this);
    if (!u.format.sanitize (c)) return TRACE_RETURN (false);
    switch (u.format) {
    case 1: return TRACE_RETURN (u.format1.sanitize (c));
    case 2: return TRACE_RETURN (u.format2.sanitize (c));
    default:return TRACE_RETURN (true);
    }
  }

Shouldn't those also be returning false?
(In reply to John Daggett (:jtd) from comment #52)
> (In reply to Behdad Esfahbod from comment #50)
> > Ugh.  Of course not.  Does that fix the issue?
> 
> Yup. :P
> 
> What about sanitize, there are a couple instance where it returns 'true' for
> unknown formats:
> 
>   inline bool sanitize (hb_sanitize_context_t *c) {
>     TRACE_SANITIZE (this);
>     if (!u.format.sanitize (c)) return TRACE_RETURN (false);
>     switch (u.format) {
>     case 1: return TRACE_RETURN (u.format1.sanitize (c));
>     case 2: return TRACE_RETURN (u.format2.sanitize (c));
>     default:return TRACE_RETURN (true);
>     }
>   }
> 
> Shouldn't those also be returning false?

Would generally work both ways.  If we return false, that would result in trying to modify the table to fix it up, which may end up in memory allocation.  We can return true though, if the rest of the methods handle it gracefully.  Sanitize() returning true means "it's safe to call other methods on this object", so as long as the rest of the code is doing the right thing we are safe here.
(In reply to Behdad Esfahbod from comment #53)

> Would generally work both ways.  If we return false, that would result in
> trying to modify the table to fix it up, which may end up in memory
> allocation.  We can return true though, if the rest of the methods handle it
> gracefully.  Sanitize() returning true means "it's safe to call other
> methods on this object", so as long as the rest of the code is doing the
> right thing we are safe here.

Ok.  Are the changes to get_glyph and get_coverage important?  I've filed a bug to pull in the latest harfbuzz from upstream but I'd like to create a minimal patch here so that we can apply it to aurora/beta/release with minimal impact.
Just fix Coverage::Iter::more to prevent infinite looping on bad fonts.
Attachment #796997 - Flags: review?(mozilla)
Attachment #796997 - Flags: review?(mozilla) → review+
(In reply to John Daggett (:jtd) from comment #54)
> (In reply to Behdad Esfahbod from comment #53)
> 
> > Would generally work both ways.  If we return false, that would result in
> > trying to modify the table to fix it up, which may end up in memory
> > allocation.  We can return true though, if the rest of the methods handle it
> > gracefully.  Sanitize() returning true means "it's safe to call other
> > methods on this object", so as long as the rest of the code is doing the
> > right thing we are safe here.
> 
> Ok.  Are the changes to get_glyph and get_coverage important?

Not as far as I can imagine.  But then again, and I'd be first to say that it's a shame, I had marked that whole commit "Minor".
(In reply to Behdad Esfahbod from comment #56)
> Not as far as I can imagine.  But then again, and I'd be first to say that
> it's a shame, I had marked that whole commit "Minor".

Well, we'll take everything on trunk as part of the harfbuzz update (bug 910506), but I think it's better to minimize the changes to be pushed to beta/release streams.

Thanks for the quick review!
Comment on attachment 796997 [details] [diff] [review]
patch, fix the coverage iterator to prevent infinite loop with bad fonts

[Approval Request Comment]
Regression caused by (bug #): 761442
User impact if declined: hangs may occur for users with buggy fonts on their system
Testing completed (on m-c, etc.): local testing with buggy font from user
Risk to taking this patch (and alternatives if risky): low, one-line modification to error case behavior
String or IDL/UUID changes made by this patch: none

Note: unfortunately it's difficult to set up an automated test for this bug.  The OT sanitizer code we use dumps the problematic GSUB table that causes the bug, so the bug only occurs with installed fonts rather than with @font-face defined fonts.
Attachment #796997 - Flags: approval-mozilla-release?
Attachment #796997 - Flags: approval-mozilla-beta?
Attachment #796997 - Flags: approval-mozilla-aurora?
Flags: needinfo?(stepand76)
Hi guys. Should I understand that it is fixed? Where I can test it?
The fix is winding its way through our build process.  It should show up in tomorrow's nightly build or the day after at the latest.

You can try out a test build here:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jdaggett@mozilla.com-8c088ede6812/try-win32/firefox-26.0a1.en-US.win32.installer.exe

Please let me know if this fixes the problem you were seeing.
Yes! It works for me! Thank you for good work!
OS: Windows 7 → All
Hardware: x86_64 → All
https://hg.mozilla.org/mozilla-central/rev/d76cd808a5fc
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla26
Comment on attachment 796997 [details] [diff] [review]
patch, fix the coverage iterator to prevent infinite loop with bad fonts

Low risk patch for a Fx23 regression.The user running into the issue ends up in with a frozen firefox.

Please land asap so this can land in today's beta, going to build in the next few hours.
Attachment #796997 - Flags: approval-mozilla-beta?
Attachment #796997 - Flags: approval-mozilla-beta+
Attachment #796997 - Flags: approval-mozilla-aurora?
Attachment #796997 - Flags: approval-mozilla-aurora+
(In reply to stepand76 from comment #62)
> Yes! It works for me! Thank you for good work!

Thanks for staying engaged with us on this report. It wouldn't be fixed right now without your help. Flagging this for verification across all branches.
Keywords: verifyme
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Firefox/24.0
Mozilla/5.0 (Windows NT 6.1; rv:26.0) Gecko/20100101 Firefox/26.0
Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Firefox/24.0
Mozilla/5.0 (X11; Linux i686; rv:26.0) Gecko/20100101 Firefox/26.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Firefox/24.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:26.0) Gecko/20100101 Firefox/26.0

Reproduced this issue with Firefox 23 beta 5 (Build ID: 20130711122148) with STR from comment 48.
Verified as fixed with Firefox 24 beta 7 (Build ID: 20130829135643) and latest Nightly (Build ID: 20130830030205).
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #44)
> We might have some data on this via telemetry chromehang reports: vladan are
> you still monitoring those regularly for new items, or does this show up
> recently?

I haven't looked at chromehang reports recently, but chromehangs wouldn't catch permanent hangs.
Btw, you can also use the hangmonitor.timeout setting for crash-on-hang behavior on non-Nightly builds.
Flags: needinfo?(vdjeric)
Alexandra, please verify this is fixed in Firefox 25.
Status: RESOLVED → VERIFIED
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.0) Gecko/20100101 Firefox/25.0
Mozilla/5.0 (X11; Linux i686; rv:25.0) Gecko/20100101 Firefox/25.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:25.0) Gecko/20100101 Firefox/25.0

Verified as fixed with latest Aurora 25.0a2 (Build ID: 20130910004002).
Attachment #796997 - Flags: approval-mozilla-release? → approval-mozilla-release-
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: