![]() ![]()
If this bug gets fixed, that simplifies code, and (I think) solves most of the problems we currently have with this particular button. #DOWNLOAD MOZILLA FIREFOX FOR MAC 10.8.5 DOWNLOAD#There are separate issues with drag/drop of/onto skipintoolbarset items that we should try to address, but really, ideally widgets added by add-ons should not be using that attribute, but instead participate fully in customization (like the download button (placeholder) currently does, too). But the simpler solution is just to make the whole thing a couple of shades less magical. Now, these two problems could have been fixed in this code, by checking more extensively for customize mode and the overflowable toolbar. #DOWNLOAD MOZILLA FIREFOX FOR MAC 10.8.5 CODE#Maybe this couldn't happen as easily on m-c because customization is something of a modal dialog, but on UX it no longer is, and so code poking the toolbar's DOM without taking that into account is liable to break in interesting ways. etc.Ģ) The dynamic moving around of the indicator happening during customization mode. The code here could implement detection for this kind of case, but really, getting rid of the magical extra button is simpler, lower maintenance, etc. This in and of itself isn't so much of a problem if we really didn't care about where the item is - but we do, it should be in the place of the placeholder (which *is* in the placements/currentset of the toolbar), and so it being moved about violates its constraints. So the problems on UX (before this patch) are twofold, AIUI:ġ) The skipintoolbarset item (indicator) having fun with our overflowing toolbar. > add-ons as well, or hit us again in the future.įirst off, UX does three things differently from m-c:ġ) rearranging widgets happens not in a (modal?) dialog but in the main documentĢ) rearranging widgets affects all windows, not just the current one > make built-in widgets avoid them, because obviously they could affect > mozilla-central? If the customization code has issues, we shouldn't just > Why is this downloads button business a problem on UX but not on (In reply to Dão Gottwald from comment #14) Otherwise, I think this should Just Work on UX, but I'm happy to deal with fallout (which I expect to be style-only) if/when. #DOWNLOAD MOZILLA FIREFOX FOR MAC 10.8.5 SKIN#the skin patches will definitely conflict on UX, but I've just described what I did so resolving that shouldn't be too tricky. #DOWNLOAD MOZILLA FIREFOX FOR MAC 10.8.5 WINDOWS#I've now also included style updates for Windows and Linux, which are basically just replacing '-indicator' with '-button' when it's at the end of the id, and adding '.indicator' if the style could (mistakenly) apply to the non-overlaid case. I've tried this with various incantations of removing/re-adding, downloading inbetween, downloading with the button removed and then re-adding this, and this seems to do the trick. Various things rely on _operational indicating whether the indicator is there, and it (a) needs to be reset more often than I thought (and before calling ensureTerminated), and (b) trying to load the overlay and setting that flag when we don't even have the placeholder (meaning the overlay won't apply to anything) is useless, so that can bail early and should never set _operational. Splinter Review I've fixed the issue that Paolo identified, I believe. Unify download-indicator and download-button, (obsolete) I don't know if some of this applies to Australis customization also, or is only an issue for Toolkit customization. Also, we don't have the styles to display the inner elements in the customization window. When the Toolkit customization window is closed, the elements are destroyed and lost forever. > Dumb question: why is it a problem if those get moved to the customizationīecause the elements are completely removed from the browser document, meaning that all our references to them are invalidated. > move those to the customization window. > removed when entering toolbar customization mode, because Toolkit would In fact, those elements would also need to > I guess there's nothing preventing us from doing that, except maybe that we ![]() > have the overlay inject the needed elements directly into downloads-button, > I wonder then if we can keep the same technique with postponed loading, but > (In reply to Mike Conley (:mconley) from comment #3) ![]() > (In reply to :Paolo Amadini from comment #4) (In reply to :Gijs Kruitbosch from comment #7) ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |