Closed Bug 396365 Opened 17 years ago Closed 17 years ago

open local svg file and open multiple windows instead...

Categories

(Core :: SVG, defect)

PowerPC
macOS
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: jay, Unassigned)

Details

Attachments

(1 file)

open any svg file such as:
https://bugzilla.mozilla.org/attachment.cgi?id=280565

maybe related to bug 395768

not perhaps strictly a hang, but requires forced quit.
I can't reproduce that with the latest Minefield builds.
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a8pre) Gecko/2007091621 Minefield/3.0a8pre

File > Open, select an svg file opens the file in a tab. No extra windows.

I did notice though that dragging a svg file from the Finder to the Dock icon of Minefield doesn't open that file (it should, isn't it ? It works for html files, jpg, png and gif files). Dragging the svg file into an open window works correctly.
#1 Philippe if the file is opening in a new tab please file a separate bug

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a8pre) Gecko/2007091622 Minefield/3.0a8pre

confirm opening new windows, wonder if window or tab is some setting

Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
wfm
No code changes --> WFM, not 'fixed'
Resolution: FIXED → WORKSFORME
as per bug 395768 reopening as latest nightlies are broken on os x

this is pretty tiresome guys, stalls SVG bug reporting and test case production
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
this bug temporarily resolved itself after a mozilla server based update to
ff2.0.0.8

with this set up when opening local svg files this dialogue pops up:

Close Firefox:

A copy of Firefox is already open. Only one copy of Firefox can be open at a time.

however once I installed the trunk nightly
firefox-3.0b2pre

it was back again....
 
os x 10.4.11
it also seema at least possible and even probable that whilst these multiple windows are opening the desktop is littered with empty files such as:
1hac8Ct4.svg.part
2jDn2i6Y.svg.part
37XNJUEo.svg.part
adKiA8mV.svg.part
Aew27Nqa.svg.part
ASa7si_s.svg.part
CbEO1Hzp.svg.part
CRRDDsJq.svg.part
IUoPtxHs.svg.part
qEuj90m7.svg.part

and many many more

cheers
#8 cheers robert,

unfortunately not possible in this instance, though certainly worth bearing in mind.

eg the dialogue or the windows appear, not both. the dialogue doesn't have a choose box, etc.

it may well be there is a relationship with bug 303581.

to be frank at the moment I've stopped using mozilla. bugs outstanding, lack of support, lack of animation, etc....
Try following the steps using Firefox 2 before using Firefox 3
#10 robert, this comment does not make sense to me.

there is no dialogue windows just open, and empty files appear on the desktop.
it's not possible afaikt to follow bug 303581 comment 3
i already tried to make this clear.
This bug started as as a report as a hang and as morphed through many stages to being a report of some sort of multiple window problem. It's a good example of why new bugs should be filed rather than reopening and morphing old one, coz I'm just simply confused now. Perhaps close this one and open a new bug with a clear description of the problem?
this bug has not morphed at all.
the symptoms disappeared for a time, and there is a fine difference between hanging, crashing, and having to close an application because it does nothing but open windows.

frankly I'm not prepared to open local svg files with mozilla until someone believes they've reproduced the problem, found a cause and believe it's rectified.

a pretty serious reason for not including svg support.
I still see no hang here. Local svg file is alocally saved copy of the testcase provided in comment 0.

Testing with Camino branch 2007112701, clean profile:

• If no windows are opened, Open File… results in a new window opening with the SVG file in it.
• If a window is opened, the SVG file opens in the tab that was active when Open File… was invoked.

Testing with Camino trunk 2007112701, clean profile will have to wait a moment. Be right back...

OK, trunk gives the same results as branch in comment 14.

Based on that and the complete lack of dupes, I'm closing this bug WORKSFORME, since only the reporter is able to reproduce it.

If you can determine a regression window and provide steps that anyone else can reproduce, please file a new UNCONFIRMED bug, including the regression window, specific steps to reproduce, and a testcase. It seems unlikely that further discussion in this bug will be productive.
Status: REOPENED → RESOLVED
Closed: 17 years ago17 years ago
Resolution: --- → WORKSFORME
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
#15

Chris did you check with the latest minefield nightly?
camino doesn't repeat this bug

there is no lack of dupes, your's is the only attempt to verify this bug.
the fact you cannot reproduce is not a reason for closing, yet.

I did check with the latest minefield.

cheers
If this is a Minefield bug, it should be filed against Minefield, not in Core. And I can't repro with Minefield either. Others have also said this works for them, so I'm going to close this one more time.

Please do NOT re-open it.
Status: REOPENED → RESOLVED
Closed: 17 years ago17 years ago
Resolution: --- → WORKSFORME
where is Minefield on os x?

I'll need to see evidence, because this is bloody awful mess for me...
and wasting a lot of time..
fwiw if you continue in your BELLIGERENT and unhelpful tone I shall close all my mozilla bugs as things are pretty dull here already.

CHEERS
Minefield application bugs should be filed in the Firefox component, with a version of "trunk".

What, exactly, do you want to see "evidence" of? This is not a court case, but even if it was, the "burden of proof" in Bugzilla has traditionally rested on the bug reporter, not the triage team or developers.

No one except you who has tried to reproduce this bug has been able to. If you don't believe that I'm telling the truth in comment 14, comment 15, and comment 17, fine, but please don't continue making a fuss over it in the bug, because it only wastes the developers' time. Your attitude is not appreciated, and I will remind you again that you should re-familiarize yourself with 

https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

before posting further.
#17

 where to file SVG component bugs for minefield, they aren't camino, core is the only other place I've found, for instance firefox & MAS do not have SVG component.

cheers

I'm going to kick this to Firefox, since it's pretty clear from comments 14-16 that this is not a Core bug.
Component: SVG → File Handling
Product: Core → Firefox
Version: unspecified → Trunk
Keywords: hang, regression
#14 & #15 appear to refer to Camino.

given your attitude and the very small a mount of testing you can possibly have done since attending to this bug, I dont consider #17 definitive.

firefox does not have an SVG component, so in which component are SVG bugs filed there? seems irrational to me.

I've lived with this bug for a couple of months and find it readily and easily reproduced.

you should not close bugs without the agreement of the reporter, most especially when they respond.

by all means ask for further info, but PLEASE DO NOT CLOSE again

I shall be taking this up with a higher authority if you continue.

no one is insisting you fix this bug.
Status: RESOLVED → REOPENED
Component: File Handling → SVG
Keywords: hang, regression
Product: Firefox → Core
Resolution: WORKSFORME → ---
Chris,

please leave my bugs alone, if you want me to move, ask.

explaining your reasons
my understanding was and is that svg in camino and minefield should be identical
hence my understanding is that as this is not camino but is SVG it should be core
(In reply to comment #25)
> my understanding was and is that svg in camino and minefield should be
> identical

Yes, they should.

Therefore, Camino should exhibit this bug.

It does not.

> hence my understanding is that as this is not camino but is SVG it should be
> core

If it were happening in Camino, I'd agree with you, but by your own admission, Camino does not exhibit this bug, therefore it cannot be a Core bug.

I have now asked you twice politely not to re-open this bug, but to file a new bug in the appropriate component with detailed steps to reproduce as well as a testcase and a regression window (if you believe it to be a regression). I will not ask a third time.
Status: REOPENED → RESOLVED
Closed: 17 years ago17 years ago
Component: SVG → File Handling
Keywords: hang, regression
Product: Core → Firefox
Resolution: --- → WORKSFORME
Chris,

I don't like your attitude, you have not explained where to file,

there is no component svg in firefox as I already explained.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
I've around 20 outstanding SVG bugs almost all filed with core.
possibly 20 or more currently fixed.
no one has ever suggested they should not be core.
If i need to move them, I need to understand why and where.
cheers
in the attachment you can delight in almost 30 files of type 0jcbdkc8.svg.part

all of these were created by simply using minefield to open a single local svg file.

of course maybe I'm imagining this, and don't have anything better to do than create empty files with strange names...
I don't doubt that you are experiencing a problem. But without anyone else being able to reproduce it, I would suggest that you may have some sort of local problem with your computer rather than a bug in Minefield.
Status: REOPENED → RESOLVED
Closed: 17 years ago17 years ago
Resolution: --- → WORKSFORME
if It's a local problem it's one that's been consistent for a couple of months.

there aren't many mac SVG testers and afaik no developers actively contributing.
tor, jwatt and robert are the ones I already know

think how we might find out what the issue might be. and try to stop pissing me off.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
copying Gerv in
Look, two of us have already said we cannot reproduce this. If you do not stop re-opening this bug, it is exceedingly likely you will find yourself without the ability to do so.

I've already asked you twice to please file a new UNCONFIRMED bug with explicit steps to reproduce, a regression window, and a testcase, yet you refuse to do so. Furthermore, you have been asked to stop commenting here unless you can comply with Bugzilla etiquette, and you refuse to do so.

Unless someone affiliated with a Mozilla.org project who is familiar with the general rules of Bugzilla triage can reproduce this, this bug should stay closed.

Am I clear?
Status: REOPENED → RESOLVED
Closed: 17 years ago17 years ago
Resolution: --- → WORKSFORME
Chris I have written to Gerv asking him to arbitrate.
please do not close again.

I have already provided steps to reproduce, and a test case.
if you advise me what and how to create a regression window I'll do my best.
Bugzilla etiquette:
"No messing with other people's bugs. Unless you are the bug assignee, or have some say over the use of their time, never change the Priority or Target Milestone fields. If in doubt, do not change the fields of bugs you do not own - add a comment instead, suggesting the change."

feel free to comment but not to change the state.

Chris to be frank this is the first time I'm aware of you interfering with my bugs. I've no idea why, your expertise in SVG is not known to me.
I've many years experience filing SVG bugs.

there is no good reason to close as yet.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
I'm particularly concerned thaqt you've moved to firefox file handling without asking or explaining to me.

I've not seen any svg files here before, which isn't to say there are none here, but....
Component: File Handling → SVG
Product: Firefox → Core
a copy of my mail to gerv, please leave state alone until arbitrated by him.

Gerv,

my apologies for copying you in to this bug.

Chris Lawson is repeatedly closing this bug, but it's not clear to me that he has any expertise with SVG at all. He's also suggested moving to firefox, which makes me doubt his sincerity.
please read the comments, I dont understand why core is wrong, but neither why MAS and FF dont have SVG component. I have about 20 other SVG bugs outstanding and need to know where they should be filed if not core.

I am more than willing to take whatever reasonable steps necessary, to provide more detail on this bug.

whenever I open any local SVG file with a nightly build, minefield trunk opens multiple windows and creates multiple empty files on my desktop extremely quickly, like 30 files and windows in 3 seconds.

this is a nuisance, most particularly because I develop SVG resources and like to check they work across user agents.
I was asked to have a look at this bug, and it took me forever to figure out what the problem was, where the STR were, etc.  We've gone from a hang to opening multiple windows to not opening files at all, if I was able to follow this progression correctly (but the summary still complains of multiple windows). This bug should have been closed INCOMPLETE a long time ago and new bug(s) filed on the new problem(s) as they developed.  No one can fix anything when they can't figure out what the problem is due to noise and morphing in the bug report.

The latest issue in this bug is almost assuredly caused by a bad MIME type locally, just as Robert Longson described in comment 8.

Please, resolve this bug INCOMPLETE and file a new, clean bug with clear, simple steps to reproduce if you can still reproduce this after deleting any incorrect SVG MIME types from your InternetConfig settings and any SVG associations from your Minefield "Applications" preferences.
Keywords: testcase
many thanks Smokey,

it's amazing how far a little kindness and help goes.

the symptoms have stopped, though

I cannot say why.
Status: REOPENED → RESOLVED
Closed: 17 years ago17 years ago
Resolution: --- → INCOMPLETE
Which is basically what I said in comment 12, and I thought I was being polite there.
Not INCOMPLETE, since per comment 39, it was probably a corrupted mimetypes.rdf.
Resolution: INCOMPLETE → WORKSFORME
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
#41

Chris you have repeatedly been asked not to change the state of this or indeed other bugs, in the case you are not the assignee.
I have already pointed you to the relevant etiquette statement.

provide a rationale by all means.
preferably one that the bug filer understands and agrees.

assuming Smokey agrees I am changing the status to wfm
Status: REOPENED → RESOLVED
Closed: 17 years ago17 years ago
Resolution: --- → WORKSFORME
OK, that's enough, both of you. :-) Leave this bug to die in peace in its current state, whatever that is.

Chris: regarding comment #15, we can't require reporters to track down regression windows - it's just not proportionate. And your tone was a little brusque.

Jonathan: regarding comment #19, throwing all your toys out of the pram when upset is not constructive.

Let's all do better next time round, OK? :-)

Gerv
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: