479778 - File locked by Firefox after uploading if Firebug is installed

Status: RESOLVED INVALID

(Core :: DOM: Core & HTML, defect)

Description

[petrus]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.0.6) Gecko/2009011913 Firefox/3.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.0.6) Gecko/2009011913 Firefox/3.0.6

With IBM Websphere Portal console, when I deploy a new WebApp, I need to select a local *.WAR file. After the deployment process, Firefox locked the local WAR file and I'm unable to overwrite/delete it. I need to use an "Unlocker" tool (http://ccollomb.free.fr/unlocker/) in order to 'kill' the lock.

Reproducible: Always

Steps to Reproduce:
1. Deploy a local WAR file in Websphere Portal (6.0.1.16)
2. Try to delete the selected WAR file after the deployment process.
Actual Results:  
The file is locked by Firefox

Expected Results:  
After the WAR upload, Firefox should not keep a lock on the local file.

about:buildconfig

Build platform
target
i686-pc-mingw32

Build tools
Compiler 	Version 	Compiler flags
cl 	14.00.50727.762 	-GL -wd4624 -wd4952 -TC -nologo -W3 -Gy -Fd$(PDBFILE)
cl 	14.00.50727.762 	-GR- -GL -wd4624 -wd4952 -TP -nologo -Zc:wchar_t- -W3 -Gy -Fd$(PDBFILE)

Configure arguments
--enable-application=browser --enable-update-channel=release --enable-optimize --disable-debug --disable-tests --enable-update-packaging --enable-official-branding --enable-jemalloc --with-crashreporter-enable-percent=10

Comment 1

[petrus]

Attachment: Unlocker prinstcreen

Comment 2

[Jo Hermans]

see bug 183689

It's also possible that it's caused by the LiveHTTPHeaders or Firebug extensions, see also bug 183689.

Comment 3

[petrus]

OK, Thanks. I confirm your idea. Without Firebuf 1.3.2, everything works fine.

Comment 4

[Jesse Ruderman]

Confirming, since this bug 183689 comment 93 says this shouldn't be duped there.

Also tracked by http://code.google.com/p/fbug/issues/detail?id=1374.  I don't think anyone knows yet whether this is a Firebug bug or a Firefox bug.

Comment 5

[Boris Zbarsky [:bzbarsky]]

See https://www.mozdev.org/bugs/show_bug.cgi?id=19262#c8 for my comments on LiveHTTPHeaders.  I'll bet that Firebug has the same problem.

If so, please mark this invalid.

Comment 6

[Boris Zbarsky [:bzbarsky]]

I should note that if necko's whole approach to POST data gets reworked as part of bug 183689 then you might be able to get away with not reading the whole stream.  If that happens (somewhat unlikely, since no one owns that code right now), we'll need some coordination to make sure that Firebug and LiveHTTPHeaders will continue to work.

Comment 7

[John J. Barton]

(In reply to comment #4)
> Also tracked by http://code.google.com/p/fbug/issues/detail?id=1374.  

Firebug has fixed our part. 

Boris, I wonder if you duped in the direction you intended? (ok by me).

Comment 8

[Boris Zbarsky [:bzbarsky]]

If you're talking about bug 183689, then yes, I did.

Sounds like this is invalid.

Comment 10

[dlorre]

I have the issue with Firebug 1.3.3 so it doesn't look fixed to me.

Comment 11

[Boris Zbarsky [:bzbarsky]]

That's something to report in the firebug bug report, not here, no?

Comment 12

[John J. Barton]

 (In reply to comment #10)
> I have the issue with Firebug 1.3.3 so it doesn't look fixed to me.

The Firebug issues list is at http://code.google.com/p/fbug/issues/list 

As a practical matter we will probably not be fixing 1.3 for this issue, so we will ask you to try Firebug 1.4X http://getfirebug.com/releases/firebug/1.4X. Auto update is broken on this version so you will need to install 1.4a18 manually when it comes out.

Comment 13

[dlorre]

Ok, the thread in http://code.google.com/p/fbug/issues/detail?id=1374
 indicated fixed for 1.3.1 or I misunderstood (it was a response to comment #7)

Comment 18

[John J. Barton]

The FIXED firebug issue is 1374
http://code.google.com/p/fbug/issues/detail?id=1374