Closed Bug 1123966 Opened 5 years ago Closed 5 years ago

fx000.tmp file remains forever after quit browser

Categories

(Core :: General, defect)

36 Branch
x86_64
Windows 7
defect
Not set

Tracking

()

VERIFIED FIXED
mozilla38
Tracking Status
firefox35 - wontfix
firefox36 - verified
firefox37 - verified
firefox38 - verified

People

(Reporter: alice0775, Assigned: m_kato)

References

Details

(Keywords: regression)

Attachments

(2 files, 1 obsolete file)

fx000.tmp files are remains in c:\users\xxxx\local\temp folder.

Steps to reproduce:
1. Open page with Flash object ( e.g. http://www.adobe.com/software/flash/about/ )
2. Quit Browser

Actual Results:
fx000.tmp file is created when open the page. (where 000; random hex numbers)
And the tmp file remains forever after quit browser.

Expected Results:
The tmp file should be removed when quit browser.

Regression window
Good:
https://hg.mozilla.org/integration/mozilla-inbound/rev/52156df5e298
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0 ID:20150113005838
Bad:
https://hg.mozilla.org/integration/mozilla-inbound/rev/0a0e57c4e420
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0 ID:20150113010126
Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=52156df5e298&tochange=0a0e57c4e420

Triggered by Bug 1120747
Flags: needinfo?(m_kato)
> fx000.tmp files are remains in c:\users\xxxx\local\temp folder.

fx000.tmp files are remains in c:\users\xxxx\AppData\local\temp folder.
Duplicate of this bug: 1123975
Perhaps FILE_FLAG_DELETE_ON_CLOSE?
Blocks: 1108035
No longer blocks: 1120747
Flags: needinfo?(m_kato)
This regression is by bug 1108035.  We should use delete on close flag on comment #3 or MoveFileEx(..., MOVEFILE_DELAY_UNTIL_REBOOT)
Assignee: nobody → m_kato
Comment on attachment 8552227 [details] [diff] [review]
Remove generated mms.cfg after closing it

We should add FILE_FLAG_DELETE_ON_CLOSE flag to remove this temporary file on close.
Attachment #8552227 - Flags: review?(aklotz)
We should be manually deleting the file. Does anyone know why that isn't working?
Comment on attachment 8552227 [details] [diff] [review]
Remove generated mms.cfg after closing it

Review of attachment 8552227 [details] [diff] [review]:
-----------------------------------------------------------------

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #8)
> We should be manually deleting the file. Does anyone know why that isn't
> working?

I'd like to know that as well. Sharing violation, maybe?

:m_kato, please can you please 
1) Try to find out why the DeleteFile call hasn't been working in the first place; and then
2) Remove the DeleteFile call as it is no longer needed with the new flag.
Attachment #8552227 - Flags: review?(aklotz)
(In reply to Aaron Klotz [:aklotz] (please use needinfo) from comment #9)
> Comment on attachment 8552227 [details] [diff] [review]
> Remove generated mms.cfg after closing it
> 
> Review of attachment 8552227 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> (In reply to Benjamin Smedberg  [:bsmedberg] from comment #8)
> > We should be manually deleting the file. Does anyone know why that isn't
> > working?
> 
> I'd like to know that as well. Sharing violation, maybe?

No. the latest Flash opens mms.cfg twice.  Second timing seems to be by newp (from PluginInstanceChild::DoNPP_New).

> 
> :m_kato, please can you please 
> 1) Try to find out why the DeleteFile call hasn't been working in the first
> place; and then

After DeleteFile, Flash will open mms.cfg again.

> 2) Remove the DeleteFile call as it is no longer needed with the new flag.

OK.  I will update fix.
Comment on attachment 8552947 [details] [diff] [review]
Use FILE_FLAG_DELETE_ON_CLOSE instead of RemoveFile

Flash 16 will open mms.cfg again after removing old temporary file.  2nd timing of opening mms.cfg isn't NP_Initialize. So, then, temporary file isn't removed correctly.

So we should use FILE_FLAG_DELETE_ON_CLOSE instead.
Attachment #8552947 - Flags: review?(aklotz)
Marking 36 as affected since the core patch landed there, and we're still considering flipping the pref.
We're not planning on using by default in 35, and it's already shipped, so wontfix there.
Attachment #8552947 - Flags: review?(aklotz) → review+
https://hg.mozilla.org/mozilla-central/rev/e43c8f946c95
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla38
Can you please request aurora/beta approval?
Flags: needinfo?(m_kato)
Comment on attachment 8552947 [details] [diff] [review]
Use FILE_FLAG_DELETE_ON_CLOSE instead of RemoveFile

Approval Request Comment
[Feature/regressing bug #]:
bug 1108035

[User impact if declined]:
Temporary file into <user profile>\AppData\Local\temp is increased.

[Describe test coverage new/current, TreeHerder]:
Landed in m-c.

[Risks and why]: 
No.  Always remove temporary file after it is closed.  It isn't re-used.

[String/UUID change made/needed]:
N/A
Flags: needinfo?(m_kato)
Attachment #8552947 - Flags: approval-mozilla-aurora?
Comment on attachment 8555069 [details] [diff] [review]
Use FILE_FLAG_DELETE_ON_CLOSE instead of RemoveFile

Approval Request Comment
[Feature/regressing bug #]:
bug 1108035

[User impact if declined]:
Temporary file into <user profile>\AppData\Local\temp is increased.

[Describe test coverage new/current, TreeHerder]:
Landed in m-c.

[Risks and why]: 
No.  Always remove temporary file after it is closed.  It isn't re-used.

[String/UUID change made/needed]:
N/A
Attachment #8555069 - Flags: approval-mozilla-beta?
Attachment #8555069 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Attachment #8552947 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
This bug has been uplifted but I don't see the need to track it.
Following the regression testing performed on Windows 7 64 bit using Nightly 38.0a1 (2015-01-28) and Aurora 37.0a2 (2015-01-28), I noticed that there are no temp files created at all while the pref is set to true (default). Makoto, is this expected?

On the other hand, if the pref is set to false, a crash similar to Bug 618686 is encountered, here's a crash ID: e469c8d8-8b09-473d-9324-b84fa2150129. This might be a separate issue altogether, but it's something I didn't manage to consistently reproduce until now, I thought I should mention it just in case.
Flags: needinfo?(m_kato)
(In reply to Andrei Vaida, QA [:avaida] from comment #24)
> Following the regression testing performed on Windows 7 64 bit using Nightly
> 38.0a1 (2015-01-28) and Aurora 37.0a2 (2015-01-28), I noticed that there are
> no temp files created at all while the pref is set to true (default).
> Makoto, is this expected?

Yes.  Before this fix, temporary file is remained into temp directory when starting Adobe flash.  After this fix, there is no temporary file (filename is fx<numbers>.tmp) into temp directory.

> On the other hand, if the pref is set to false, a crash similar to Bug
> 618686 is encountered, here's a crash ID:
> e469c8d8-8b09-473d-9324-b84fa2150129. This might be a separate issue
> altogether, but it's something I didn't manage to consistently reproduce
> until now, I thought I should mention it just in case.

This is another issue.  It isn't related to this.
Flags: needinfo?(m_kato)
(In reply to Makoto Kato (:m_kato) from comment #25)
> (In reply to Andrei Vaida, QA [:avaida] from comment #24)
> > Following the regression testing performed on Windows 7 64 bit using Nightly
> > 38.0a1 (2015-01-28) and Aurora 37.0a2 (2015-01-28), I noticed that there are
> > no temp files created at all while the pref is set to true (default).
> > Makoto, is this expected?
> 
> Yes.  Before this fix, temporary file is remained into temp directory when
> starting Adobe flash.  After this fix, there is no temporary file (filename
> is fx<numbers>.tmp) into temp directory.
Thank you for the quick reply, Makoto. This is verified fixed then, I'll follow up with test results for m-b as soon as a build containing the fix is available there as well.

> > On the other hand, if the pref is set to false, a crash similar to Bug
> > 618686 is encountered, here's a crash ID:
> > e469c8d8-8b09-473d-9324-b84fa2150129. This might be a separate issue
> > altogether, but it's something I didn't manage to consistently reproduce
> > until now, I thought I should mention it just in case.
> 
> This is another issue.  It isn't related to this.
As for the other issue, I'll investigate it further and file a separate bug if necessary.
Verified fixed on Firefox 36.0b5 (20150129200438) as well, using Windows 7 64 bit.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.