Closed Bug 528755 Opened 13 years ago Closed 13 years ago

Find a place for filepicker's filter strings to live

Categories

(Core :: Widget, defect)

All
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Tracking Status
status1.9.2 --- beta4-fixed

People

(Reporter: neil, Assigned: neil)

References

(Blocks 1 open bug)

Details

(Keywords: regression)

Attachments

(2 files, 1 obsolete file)

The strings in filepicker.properties are used in two places. Presumably when they were originally added in the same file because it was easier (pavlov has blame so you could always try asking him, if he can remember 10 years back...)

Bug 504822 removed one of the strings and one of its consumers, thus breaking the other consumer. What's the right fix here?
1. Restore the deleted filter (OK, probably not, but listed for completeness)
2. Make both consumers hardcode the filters (but problems when changing them)
3. Create a new properties file in content for all of the original filters?
Flags: blocking1.9.2?
Attached patch Possible patch (obsolete) — Splinter Review
This implements option 3. I did have a patch for option 2, but I accidentally overwrote it whilst creating this one :-(
Assignee: nobody → neil
Status: NEW → ASSIGNED
Attachment #412472 - Flags: review?(gavin.sharp)
Trying this patch with a new build of my SM 2.1 gives:

processing /home/hafi/moz-work/src/mozilla/toolkit/content/jar.mn
Traceback (most recent call last):
  File "/home/hafi/moz-work/src/mozilla/config/JarMaker.py", line 498, in <module>
    main()
  File "/home/hafi/moz-work/src/mozilla/config/JarMaker.py", line 495, in main
    localedirs=options.l10n_src)
  File "/home/hafi/moz-work/src/mozilla/config/JarMaker.py", line 286, in makeJars
    jardir=jardir)
  File "/home/hafi/moz-work/src/mozilla/config/JarMaker.py", line 231, in makeJar
    localedirs)
  File "/home/hafi/moz-work/src/mozilla/config/JarMaker.py", line 352, in processJarSection
    outHelper, jf)
  File "/home/hafi/moz-work/src/mozilla/config/JarMaker.py", line 384, in _processEntryLine
    raise RuntimeError('File "%s" not found in %s' % (src, ', '.join(src_base)))
RuntimeError: File "filepicker.properties" not found in /home/hafi/moz-work/src/mozilla/toolkit/content, .
Attached patch Possible patchSplinter Review
D'oh, I forgot to hg add that file...
Attachment #412472 - Attachment is obsolete: true
Attachment #412494 - Flags: review?(gavin.sharp)
Attachment #412472 - Flags: review?(gavin.sharp)
This time i cannot test the patch. The build fails already at
gmake[7]: *** No rule to make target `/home/hafi/moz-work/src/obj-i686-pc-linux-gnu/mozilla/dist/lib/libunicharutil_s.a', needed by `libuconv.so'.  Stop.

;)
You must have a problem with your build somewhere, that error occurs before your previous error, in a part of the code my patch doesn't even change.
(In reply to comment #5)

> You must have a problem with your build somewhere, that error occurs before
> your previous error, in a part of the code my patch doesn't even change.

I know that this has nothing to do with your patch. But i cannot test it as long as my builds fail. ;)

The error message points to https://bugzilla.mozilla.org/show_bug.cgi?id=462381 but the tree isn't red. Hm.

And i shouldn't have commented in this bug. Sorry.
(In reply to comment #6)
> The error message points to https://bugzilla.mozilla.org/show_bug.cgi?id=462381
> but the tree isn't red. Hm.
Maybe the tinderboxen don't use a high enough -j factor to trigger the bug.

> And i shouldn't have commented in this bug. Sorry.
Well, you were right to comment the first time ;-)
(In reply to comment #4)
>gmake[7]: *** No rule to make target
>`/home/hafi/moz-work/src/obj-i686-pc-linux-gnu/mozilla/dist/lib/libunicharutil_s.a',
>needed by `libuconv.so'.  Stop.
A bustage fix for this has just landed on mozilla-central.
> A bustage fix for this has just landed on mozilla-central.

I know and i have already verified, that your patch works for me. Now i am happy again with the Modern filepicker. :)
Component: ImageLib → Widget
QA Contact: imagelib → general
We are hard frozen on strings. This can't block 1.9.2.
Attachment #413208 - Flags: review?(gavin.sharp)
Attachment #413208 - Flags: review?(gavin.sharp) → review+
Sufficient for me to get the filepicker of Modern.
Flags: blocking1.9.2? → blocking1.9.2+
Neil checked the minimal fix in: http://hg.mozilla.org/mozilla-central/rev/30c2cf6bdf2f and http://hg.mozilla.org/releases/mozilla-1.9.2/rev/4546ea430ba5. I'll spin off another bug about fixing it properly (involving strings) on mozilla-central.
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Comment on attachment 412494 [details] [diff] [review]
Possible patch

>diff --git a/toolkit/locales/en-US/chrome/global/filepicker.properties b/toolkit/locales/en-US/chrome/global/filepicker.properties

>-# LOCALIZATION NOTE FILE
>-# --do not localize the extensions, only the titles
> allTitle=All Files
>-allFilter=*
> htmlTitle=HTML Files
>-htmlFilter=*.html; *.htm; *.shtml; *.xhtml
> textTitle=Text Files
>-textFilter=*.txt; *.text
> imageTitle=Image Files
> xmlTitle=XML Files
>-xmlFilter=*.xml
> xulTitle=XUL Files
>-xulFilter=*.xul
> appsTitle=Applications

Worth adding the extensions in localization notes, to indicate what file types the title should cover, perhaps (or refer to the other filepicker.properties)?
Attachment #412494 - Flags: review?(gavin.sharp) → review+
Comment on attachment 412494 [details] [diff] [review]
Possible patch

Pushed changeset 900590ea829b to mozilla-central.
You need to log in before you can comment on or make changes to this bug.