How's pdf rendering in Firefox? Chrome headless has its issues with headers and footers
I just used Chrome headless to render several thousand pdfs last week and I saw no issues in version 73
Prototype: Puppeteer for Firefox
41–50 of 133 posts
Re: Prototype: Puppeteer for Firefox
#42Earlier quoted context omitted.
After Firefox broke most extensions with their removal of XUL extensions and embrace of "WebExtensions" (aka Chrome extensions), it lost a major differentiation point from Chrome. People simply have no (immediate, practical) reason to use Firefox. Back in the Mozilla days i was using Mozilla because it was very powerful and flexible despite being very slow (i remember watching Mozilla 0.6's dialog boxes draw themselv…
It also doubled in speed. As a long term FF user (and webdev), I was over the moon to trade in a few extensions for that sort of performance boost. A year or so after the fact, I can't even remember what I've lost. Couldn't have been that important.
It became faster (not sure about double though) but i still remember losing MAFF, DownThemAll and a bunch of other addons. More importantly it is the functionality that was lost for new addons to be made that could provide features not thought by anyone before.
Re: Prototype: Puppeteer for Firefox
#43Re: Prototype: Puppeteer for Firefox
#44Earlier quoted context omitted.
After Firefox broke most extensions with their removal of XUL extensions and embrace of "WebExtensions" (aka Chrome extensions), it lost a major differentiation point from Chrome. People simply have no (immediate, practical) reason to use Firefox. Back in the Mozilla days i was using Mozilla because it was very powerful and flexible despite being very slow (i remember watching Mozilla 0.6's dialog boxes draw themselv…
Firefox actually is FASTER that Chrome. Also, if you have any privacy concerns, you should stop using Chrome ASAP.
I never used Chrome as a main browser (though i do use it sometimes for its automatic translation).
Performance is ok but it isn't my main concern, i'm also concerned about features (after all lynx is faster than both of those browsers, yet it lacks a bit on the features side).
In any case, this isn't a hill i care to die on. I just do not see much of a difference between the two browsers anymore in terms of what they can do. I used to like Mozilla for its features (in fact i was really annoyed that they switched their focus to Firefox back in the day and left what they renamed to "Mozilla Suite" to die) and Firefox later for its (remaining) features. Funny enough now that i think about it, the reason was also "performance" back then and again i didn't care about it but i did care about the features lost.
I guess they kept on the same path and eventually Firefox will be a chromeless, featureless HTML terminal - not very useful as a browser, but it'll be the fastest HTML terminal :-P.
Re: Prototype: Puppeteer for Firefox
#45Earlier quoted context omitted.
After Firefox broke most extensions with their removal of XUL extensions and embrace of "WebExtensions" (aka Chrome extensions), it lost a major differentiation point from Chrome. People simply have no (immediate, practical) reason to use Firefox. Back in the Mozilla days i was using Mozilla because it was very powerful and flexible despite being very slow (i remember watching Mozilla 0.6's dialog boxes draw themselv…
Firefox actually is FASTER that Chrome. Also, if you have any privacy concerns, you should stop using Chrome ASAP.
Firefox is faster than Chrome with their synthetic benchmarks.
Re: Prototype: Puppeteer for Firefox
#46Earlier quoted context omitted.
It's much more reliable.
How? With selenium I have a case that WebElement.click() fails but it doesn’t throw. Also Select(...).select_by_visible_text() throws WebDriverException, StaleElementException, etc even if you WebDriverWait()’d for it to be available. To me these show selenium is unreliable. How puppeteer is reliable pertaining to these cases?
It's probably because in the meantime dom nodes has been replaced by new ones.
Selenium has it's quirks but when you understand how it works and it's limitations and user centric philosophy there is nothing that can stop you from writing rock solid stable tests.
Re: Prototype: Puppeteer for Firefox
#47great work on firefox on github.com
nice one
require attention by all developers on github
check it out
Re: Prototype: Puppeteer for Firefox
#48Re: Prototype: Puppeteer for Firefox
#49Earlier quoted context omitted.
Yeah, that doesn't answer my question though ;)
Merging them in a single package gives you nothing at a significant price. puppeteer = wantFox ? require('puppeteer-firefox') : require('puppeteer')
Sure but now there are two separate codebases for the same API. A lot of code will be duplicated between the two codebases, you'll have to maintain two sets of issues on github etc.
If it were me I would aim to merge the firefox puppeteer into chrome puppeteer but fair enough if they want to keep them separate.
EDIT: I guess it depends on how much of the code in the puppeteer chrome codebase is tightly coupled to chrome dev tools. Like if 25% of specific to chrome, then that would mean that 75% of the code can be shared between the chrome implementation and the firefox one, in that case I think merging and hiding the 25% chrome/firefox specific stuff behind an abstraction layer is the best option.
Re: Prototype: Puppeteer for Firefox
#50This is nice work. Does anyone know if it's possible to enable reader view "programatically", though?
Sure, just go to `about:reader?url=whatever`
Or did you mean something else?