Suggestion : non-uglyfied bundle.js distribution + make it modding-friendlier



  • Hello, Customization/extension of browser's behaviour/UI is currently very painful : [ol] [li]bundle.js code is cryptic[/li] [li]module ids are not stables. (eg : module 344 is currently the module responsible for tabs, but in future versions it might be something else, so we can't safely create a mod to replace it.)[/li] [li] module ids aren't meaningful (eg : 344 instead of "path/to/tabs").[/li] [/ol] [b]Suggestions : [/b] [b]for 1 : [/b] release bundle.js input's source (maybe without modules from nodejs, react, etc.) [b]for 2 and 3 : [/b] use [i]--full-paths[/i] browserify's option to generate bundle.js I assume Vivaldi planed something smart to take profit of customization-friendliness that a javascript/css/html frontend could provide. But until then, it would quickly allows us to do deeper customizations. NB : Additionally, a standard interface to require/inject/replace modules from user's code could be nice (but less important, see davesnothere's reply). Edit : used my (clearer) reply. Original post was : [quote] Hello, Is the distribution of the bundle.js 's source-code (non uglyfied, multi-files (text-editor-friendly), and in whatever language used to generate it) planed ? It would be very cool to be able to generate it ourself using node-js, instead of slowly figuring out what's going on with the "compiled" version. Additionally, public methods could be added to ModulesManager (or whatever its real name is : the first "e" function in bundle.js) to allow injection/replacement of modules via a standardize interface ; without having to modify bundle.js itself, and thus enjoying its future updates automatically (but its source code would still be very helpful, under a license that allows modification+distribution) eg : // only for modders, bundle.js can continue to use constructor. /void/ injectModule(/string/friendlyModuleName, /int/moduleId. /function/ module) // returns module's exports object, only for modders since modules in bundle.js get a require-like function as argument anyway /object/ requireModule( moduleNameOrId ) // called last by another js file (or inlined script), so we could use injectModule() from files linked (after browser.js) in browser.html, to replace vanilla modules before they get executed. /void/ executeMainModules() [/quote]



  • @OVNI:

    …. // called last by another js file (or inlined script), so we could use injectModule() from files linked (after browser.js) in browser.html, to replace vanilla modules before they get executed….

    ~
    I think that someone wrote and posted a link to a modification/extension here which loaded in that manner, a few days ago.

    They did not explain at first how it worked, but upon my asking what to do with all of the files, I was instructed (among other details) to replace the default browser.html file with theirs, which, upon my closer inspection, I discovered that it had been edited to load their custom JS files too.
    ~



  • Thanks for your answer, but there's still major issues :

    1. bundle.js isn't human-friendly at all. It's the biggest issue.
    2. module ids are probably not stables. For example 344 is currently the module responsible of tabs behavior, but in future versions it might be something else, so we can't safely replace it.
    3. module ids aren't meaningful (ie : 344 instead of "tabs", and we can't really make a list/map since modules ids may change anyway).

    All of them could only be fixed by Vivaldi devteam :

    1. by releasing bundle.js input's source (well, maybe not the 3rd party libs like nodejs, react, etc. We can still download it ourselves if needs be…)
      2 and 3) by using --full-paths option of browserify

    I assume Vivaldi devteam planed something smart to take profit of customization-friendliness that a css/js/html frontend could provide.
    But until then, it would quickly allows a lot of deep customizations.



  • @OVNI:

    Thanks for your answer, but there's still major issues :

    1. bundle.js isn't human-friendly at all. It's the biggest issue.
    2. module ids are probably not stable. For example 344 is currently the module responsible of tabs behavior, but in future versions it might be something else, so we can't safely replace it.
    3. module ids aren't meaningful (ie : 344 instead of "tabs", and we can't really make a list/map since modules ids may change anyway).

    All of them could only be fixed by Vivaldi devteam :

    1. by releasing bundle.js input's source (well, maybe not the 3rd party libs like nodejs, react, etc. We can still download it ourselves if need be…)
      2 and 3) by using --full-paths option of browserify

    I assume Vivaldi devteam planned something smart to take profit of customization-friendliness that a css/js/html frontend could provide.
    But until then, it would quickly allow a lot of deep customizations.

    ~
    Yes, plenty of issues remain.

    (1) I agree fully about bundle.js being a hostile environment, and sorry for not saying so sooner. ;)

    (2) and (3) If I had a standalone list of those module ID's in front of me, I could at least get further than I can right now in tweaking the other code.

    There ARE some things which I have been trying to modify, but the cryptic nature of the module IDs, and also of frequently used variables (such as e, t, r, and some other single letter ones), is making all it too abstract for this aging programmer's mind. :unsure:

    I also do not recognize an external module title when I see one, as I am new to JS (though I have programmed in plenty of other languages), so a standalone list of their names would also help me.

    That all said, I HAVE managed to make a few modifications, such as changes, additions and rearrangements to the main menu structure, and have enjoyed limited success in the creation of extra buttons, but it has been slow going for all of the reasons which we both have said.
    ~



  • I've gave up trying to mod Vivaldi for now, but if it could be of some use, here's my progresses :<br /><br />An understandable version of the module manager (the first "e" function), which also helps to understand the meaning of modules' parameters :<br /><spoiler><br /><pre>
    /**

    • @param {Object<int,Array>} modules

    • A map with moduleId as key, and an Array with 2 elements as value.

    • The first array element is a function (the module itself), and the second element an object for internal modules (which Vivaldi never uses).

    • @param {Object} modulesCache

    • An Empty object {} used to store modules already executed (i don't know why it's a parameter instead of an internal variable)

    • @param {Array} mainModuleIds

    • An array containing ids of main modules (Vivaldi has only one main module).

    • @returns {function} for some reason...
      */
      function ModulesManager( modules, modulesCache, mainModuleIds ) {
      var that = this;

      /**

      • Behaves like nodjs' require.

      • The first time a module is required, this module is executed and exports object is cached.

      • @return {object} "exports" object containing stuff exposed by required module.
        */
        this.require = function( moduleId ) {

        if( !modulesCache[moduleId] ) {
        if( !modules[moduleId] ) {
        // try using nodejs's require (witch isn't available in browser...)
        var nodejsRequire = typeof require === "function" ? require : null;
        if( nodejsRequire ) {
        return nodejsRequire(moduleId, !0);
        }
        // of course it failed...
        var ex = new Error("Cannot find module '" + moduleId + "'");
        ex.code = "MODULE_NOT_FOUND";
        throw ex;
        }

        // execute module (once) and add it to cache
        var module = { exports : {} };
        modulesCache[moduleId] = module;
        modules[moduleId][0].call(
        	module.exports,
        	function( otherModuleName ) {
        		var internalModule = modules[moduleId][1][otherModuleName];
        		return that.require(internalModule ? internalModule : otherModuleName)
        	},
        	module, module.exports, that, modules, modulesCache, mainModuleIds
        );
        

        }

        return modulesCache[moduleId].exports;
        };

      // execute main modules
      for( var moduleId = 0; moduleId < mainModuleIds.length; moduleId++ ) {
      this.require( mainModuleIds[moduleId] );
      }

      return this.require;
      }
      </pre></spoiler><br /><br />Some module ids painfully inferred :<br /><spoiler><br />// react : 211<br />// events : 9 // nodejs<br />// path : 10 // nodejs<br />// url : 16 // nodejs<br />// tab : 344<br />// gesture : 283 // mouse gesture (attached to #browser)<br />// 220,223 // actions (mousegesture / hotkeys / quickcommands)<br />// 17 // react?<br /></spoiler><br /><br />Some more module ids (based on displayName given to react's createClass() ) using perl :<br /><pre>perl -ne 'while(m/(\d+):[function.+?displayName:"(.+?)"/sg){print "$1=$2\n";}' bundle.js[/code]
      [spoiler]
      57=ReactCSSTransitionGroup
      73=ReactCSSTransitionGroupChild
      74=ReactDOMButton
      86=ReactDOMForm
      88=ReactDOMIframe
      90=ReactDOMImg
      91=ReactDOMInput
      92=ReactDOMOption
      93=ReactDOMSelect
      94=ReactDOMTextarea
      116=ReactTransitionGroup
      144=ReactFullPageComponent
      213=BookmarksManager
      227=BookmarksPanel
      228=BookmarksBar
      229=BookmarksBarItem
      230=BookmarksFoldersFlatList
      231=BookmarkEditItem
      233=BookmarkItem
      234=BookmarkTree
      235=VivaldiDropdown
      236=MultiInput
      242=RadioGroup
      244=SlideBar
      247=TreeNode
      248=Menu
      249=MenuItem
      250=ContactGroupView
      254=ContactPage
      256=ContactTree
      257=ContactView
      258=ContactsPanel
      259=CreateBookmark
      261=Modal
      262=DialogRenderWrapper
      263=DownloadDialog
      264=ImportBookmarks
      265=JavascriptDialog
      266=DownloadItem
      267=Draggable
      268=FindInPage
      269=History
      270=FullscreenInfoBubble
      271=MailPanel
      273=StatusInfo
      275=PopupWindow
      276=AttachmentItem
      285=ActionItem
      286=Panel
      287=PageloadProgress
      288=ProgressIndicator
      290=SearchField
      291=RestartBrowserDialog
      292=CookieExceptionItem
      293=CookieExceptionsSetting
      294=CookieItem
      295=CookieManager
      296=CookieManagerDialog
      297=CookieSettings
      298=DownloadSettings
      299=LanguageSetting
      301=Privacy
      302=QuickCommandDialog
      303=QuickCommandItem
      304=QuickCommandSearch
      305=SavedPasswordItem
      306=SavedPasswords
      307=CreateSearchEngine
      308=CreateSearchEngineDlg
      309=SearchEngines
      310=SearchEngines
      311=Settings
      312=ShortCutEditSetting
      313=ShortCutSetting
      314=AddressBar
      315=Appearance
      316=BookmarkBar
      317=FullscreenSettings
      318=MenuType
      319=NetworkSettings
      320=Panels
      321=SetVivaldiDefaultBrowserDlg
      322=VivaldiDefaultBrowser
      323=ShortcutKeySettings
      324=StartupSetting
      325=StartupSettingSection
      326=TabCyclingOrder
      327=TabPosition
      328=TabStacking
      329=TabsSettingSection
      330=Sync
      331=ToggleImages
      332=ToggleTiling
      333=SpeedDialAddButton
      334=SpeedDialDrawer
      335=SpeedDialAddContent
      336=EditableSpeedDialTitle
      337=SpeedDialView
      338=SpeedDial
      339=StartPageTopMenu
      342=StartPage
      343=TabBar
      344=Tab
      345=Trash
      346=Thumbnail
      347=TitleBar
      349=Tooltip
      350=LocationNotImplementedDialog
      351=LocationPermissionNotificator
      352=MediaPermissionDialog
      353=MediaPermissionNotificator
      354=NavigateButton
      355=OmniDropdown
      356=PopupBlockerDialog
      357=PopupBlockerNotificator
      358=UrlBar
      359=UrlField
      360=WebPage
      362=WebPageView
      363=ZoomIndicator
      [/spoiler]</pre>


Log in to reply
 

Looks like your connection to Vivaldi Forum was lost, please wait while we try to reconnect.